* Add a new post install software deployment which runs
a python script to configure the undercloud control
plane network. Replaces section in post shell script.
In I75f087dc456c50327c3b4ad98a1f89a7e012dc68 we removed much of
the legacy upgrade workflow. This now also removes the
disable_upgrade_deployment flag and the tripleo_upgrade_node.sh
script, both of which are no longer used and have no effect on
Stdin does not work for the 'openstack keypair create' command
used in extraconfig/post_deploy/undercloud_post.sh, when installed
via Heat templates.
This ends up with different keys created for underlcoud admin and
the default nova keypair, which is configured by Ironic for
overcloud nodes. So those can not be contacted by undercloud
admin via SSH.
The deployed-server/scripts/enable-ssh-admin.sh fails w/o
that fix and makes not possible to deploy BM/OVB overcloud on top
of UC installed with Heat.
Co-authored-by: Harald Jensas <firstname.lastname@example.org>
Signed-off-by: Bogdan Dobrelya <email@example.com>
openshift-ansible allows for passing boot time arguments to the
openshift nodes as well as other variables through the inventory. By
adding the OpenShift(Master|Worker)NodeVars variable, we'll allow for
these variables to be set and customized per deployment.
Co-Authored-By: Martin André <firstname.lastname@example.org>
Since Pike, minor updates are done via the composable services
framework. The old shell script approach hasn't been used/tested for 2
releases now, and should be dropped.
Also drop the UpdateWorkflow interface. Before we started doing
upgrades via Ansible, we used this pluggable resource interface to
perform oneshot operations like migrations to WSGI or AODH
services. Nowadays this interface is not referenced from anywhere and
we'd probably rather do similar operations via Ansible tasks.
Instead of disabling openvswitch managed by TripleO when deploying
OpenShift, we should tell OpenShift to let TripleO manage it. We're
going down this path on the openshift-ansible path so we'll stop
disabling openvswitch in t-h-t.
- Replicate what has been done in _post_config_mistral
- Cleanup cron triggers before cleaning workflows.
- Re-create publish-ui-logs-hourly cron trigger.
- If validations are enabled, execute copy_ssh_key workflow.
When enabling network isolation, openshift-ansible picks the wrong ip
address as the default IP for the services. Set the IP to the ctrlplane
network by default, which works with and without network isolation.
This can be used in the case where e.g a satellite has been added
after the initial deployment to re-register the nodes with the
satellite, even those nodes that already exist.
The default control plane subnet name is "ctlplane-subnet", so let's
create the right subnet for the containerized undercloud.
Note: the subnet can't be overriden (yet) but for now we rely on the
We want to configure a TLS url for the underclouds stackrc
when a user specified or generated TLS certificate is used.
This patch updates the existing check so that
the PublicSSLCertificateAutogenerated paremeter is also used
when deciding if the SSL URL should be enabled.
This allows deploying openshift from the packaged openshift-ansible or
from a git checkout more easily, by setting the
OpenShiftAnsiblePlaybook heat environment variable.
In the PreNetworkConfig, the order of resources sent to os-collect-config
changed after introducing vhost user resource. The current order is
3. RebootDeployment and EnableDpdkDeployment
Here the expectation is that RebootDeployment should be completed
before enabling DPDK, but since both are provided at the same time to
os-collect-config, DPDK is enabled first. The reson is RebootDepolyment
is having signal transport as NONE and EnableDpdkDeployment is moved
after reboot because of ovs2.7 change of restart vswitchd, when DPDK is
enabled. This is causing the a failure.
This patch modifies the order as below:
1. HostParametersDeployment and DpdkVhostGroupDeployment
2. RebootDeployment and RebootEnsureDeployment
We're deploying containerized OpenShift, which means openshift-ansible
deploys also containerized OVS. When not disabled explicitly, the bare
metal OVS service seemed to persist at least partially, and it likely
caused issues with the containerized OVS, where nodes in `kubectl get
nodes` would go from Ready status to NotReady shortly after the
Some of the options that had been hard-coded in the openshift-master
template should be configuratble in a per-deployment bases. This patch
moves them out into an environment file instead.
This will allow arbitrary config of global variables for
openshift-ansible, e.g. customizing SDN params according to:
Also remove the setting which was meant to disable OVS service
handlers in openshift-ansible -- that wouldn't solve the problem
Till now, the ovs service file and ovs-ctl command files
are patched to allow ovs to run with qemu group. In order
to remove this workarounds, a new group hugetlbfs is created
which will be shared between ovs and qemu. This patch contains
the changes required for applying these changes.
The output comes from ansible and is already fully readable as it is.
Also, because the previous task didn't have the 'failed_when: false'
directive, it would never reach the 'print xxx outputs' task in case of
failure, while showing the output twice on success.
It is safe to just delete the task.
The first phase sets up the node-to-node tunnels at step 1; this
ensures that the corosync cluster setup is done over the tunnels
and prevents any timeouts that were happening when the setup was
done after the cluster was up. This has the added value that all
the pacemaker communication is encrypted from the beginning.
The second phase is the VIP tunnel setup, which is in step 3. This
is because we need the VIPs to be setup by pacemaker, and we also
need pacemaker to be up.
The *-variables.conf file for tuned is hardcoded for the profile
"cpu-partitioning", which makes other profiles fail, that also need
the isolated_cores variable.
This converts "tags: stepN" to "when: step|int == N" for the direct
execution as an ansible playbook, with a loop variable 'step'.
The tasks all include the explicit cast |int.
This also adds a set_fact task for handling of the package removal
with the UpgradeRemovePackages parameter (no change to the interface)
The yaml-validate also now checks for duplicate 'when:' statements
Q upgrade spec @ Ibde21e6efae3a7d311bee526d63c5692c4e27b28
Related Blueprint: major-upgrade-workflow
: 394a92f761/tripleo_common/utils/config.py (L141)