host_prep_tasks are run from deploy_steps_playbook.yaml, so there's no
need to also run them as part of the {{role}}HostPrepDeployment
resources.
Change-Id: If1bf6dda19e6e0b875463c421f9504efab85251b
Problem: RHEL and CentOS8 will deprecate the usage of Yum.
From DNF release note:
DNF is the next upcoming major version of yum, a package
manager for RPM-based Linux distributions.
It roughly maintains CLI compatibility with YUM and defines a strict API for
extensions.
Solution: Use "package" Ansible module instead of "yum".
"package" module is smarter when it comes to detect with package manager
runs on the system. The goal of this patch is to support both yum/dnf
(dnf will be the default in rhel/centos 8) from a single ansible module.
Change-Id: I8e67d6f053e8790fdd0eb52a42035dca3051999e
There is a CI blocker LP 1782598 to deal with ASAP.
Then, we can fix this in the scope of
https://review.openstack.org/#/c/584119/
This reverts commit 915c1ebdd79fecb57a0719997a56c34685307431.
Change-Id: I8f03d8a588e58202c3628c72144a232729041c89
If an operator has non-paunch managed containers (ceph/openshift), we
may not want to fail the deployment if those are unhealthy.
Change-Id: Ifd3e67a66b3224d0ed5f7ef12ba27b06f78c8556
After starting the containers, we should make sure they are healthy
before continuing. If any containers are unhealthy we should fail
quickly and provide output showing which container is unhealthy.
Change-Id: I785ddb45779b6699fc839fdddb9c804dd1b1da5d
Deploy steps run the docker puppet steps with max of
a 3 processes. This takes like 30 min to finish the
containers configuration for a typical overcloud (in CI).
Double the numbers to allow more puppets finish threir
tasks sooner.
Change-Id: Id0b0371e7f21f56528027921732ade786525d659
Signed-off-by: Bogdan Dobrelya <bdobreli@redhat.com>
include module is deprecated. The alternate is to use import_tasks
for static file tasks inclusion and include_tasks for dynamic tasks
file inclusions (like using with_items).
Change-Id: I8b3bf3ba3d7c2cfbe1187218c51f619e65efe0e5
We drop the post_update_steps_playbook, and execute post_update_tasks
as part of the update_steps_playbook. This will ensure that
post_update_tasks are executed, and they're executed in accordance
with the `serial: 1` ordering that update_steps_playbook is using. (We
want to avoid an issue similar to what we've had in bug #1776206).
Change-Id: I15a984172cd5532bc966269d8c68f27b5703733e
Closes-Bug: #1778471
The ansible command generated in ansible-playbook-command.sh by default
have "--become" in it.
This commit removes "become: true" where is used to avoid confusion in
deploy steps. Today we explicitly set "become: false" in deploy-steps.j2
for certain actions, so there's no meaning of having also "become: true"
for the other ones.
We have a release note [1] that explains why the "become" was
introduces, but maybe we can revisit it.
[1] releasenotes/notes/use-become-true-in-deploy-steps-playbook-01decb18d895879f.yaml
Change-Id: Ic666b4ecaecf0591dd8bb0406f239649b20b9623
We should re-run host_prep_tasks as part of the minor update, to make
sure the host is ready for starting the updated containers. The right
place for them is between update tasks and deployment tasks.
This is important in case we deliver changes to host_prep_tasks during
minor update, or if update_tasks do something that would partially
undo the host preparation, e.g. clear/delete some directories on the
host to get rid of previous state.
Change-Id: Ic0a905a8c4691cbe75113131bd84e8a39dea046d
Related-Bug: #1776206
- do not use set_fact when a lookup can be done directly in the task
- use multi-line YAML for easier legibility
- ignore errors in file lookup plugin when file does not exist and set defaults
Change-Id: I832a2ec34f4ed4a87e30d0c88f4c60bcf2f4c151
In order to make the deployment more flexible, we should allow for the
ansible hosts to be configurable from the old undercloud/overcloud
concepts. Rather than assume 'undercloud'/'overcloud', we should allow
for these to include the same set of hosts. This change introduces
'deployment_source_hosts' and 'deployment_target_hosts' variables that
can be used to control where the tasks are run on.
Change-Id: I249cc7e179bc1423788aab967c4b2e3f9ffc81d4
Related-Blueprint: all-in-one
In I4b576a6e7fbfb18fa13221e2d080bf7876a8303e state information
will be persisted in Swift and the name of the Swift container
should be a function of the Heat stack in case multiple stacks
are deployed. This patch passes the name of the Heat stack to
the Mistral environment so that the workflow may access the
Heat stack name and name the Swift container accordingly.
Change-Id: I995ad32345a39238ffb9cbcf9966dedc60c75ff8
Related-Bug: #1769769
This should merge multiple and different values for the same key
found in different services.
For example, assuming two services defining a key as follows:
config_settings:
mykey:
- val1
config_settings:
mykey:
- val2
- val3
the content of the key, as seen by ansible or puppet on the nodes,
will be:
mykey: ['val1','val2','val3']
Change-Id: I190374e36ad1a2b57611a3a9d0a52ceb1a049aff
"role_name" is internal to Ansible, we should not use it.
This patch uses the new variable set in the inventory to use a specific
TripleO var: tripleo_role_name which is the TripleO role name and not
the Ansible role names, both things are very different.
Depends-On: I57c4eac87e2f96dfe5490b111cd2508505715d56
Change-Id: Iecaf6f1b830e65be2f9e2e44431054fe46f9f565
Related-Bug: #1771171
For NFV deployments, specific kernel args should be applied and
the nodes should be restarted before running the NetworkDeployment.
It is supported in the heat deployment via PreNetworkConfig. In the
config-download mechanism, ansible steps need to be improved
to handle the reboot and wait for the node.
Change-Id: I43b383ad0e04b8be6c321f8c5b05e628b2520141
The new master branch should point now to rocky.
So, HOT templates should specify that they might contain features
for rocky release [1]
Also, this submission updates the yaml validation to use only latest
heat_version alias. There are cases in which we will need to set
the version for specific templates i.e. mixed versions, so there
is added a variable to assign specific templates to specific heat_version
aliases, avoiding the introductions of error by bulk replacing the
the old version in new releases.
[1]: https://docs.openstack.org/heat/latest/template_guide/hot_spec.html#rocky
Change-Id: Ib17526d9cc453516d99d4659ee5fa51a5aa7fb4b
This patch adds the primary role name as the first host pattern in the
individual plays in deploy-steps.j2. This will ensure that the primary
role will execute tasks first, which is needed so that all Pacemaker
nodes run the same step at the same time.
Change-Id: I9c499be87ce51ae28914b013b4b91446a3a68015
Closes-Bug: #1768238
So far we haven't been disabling workflows for update/upgrade. We
should disable them by default as they could have the potential to
disrupt the update/upgrade/ffwd procedure.
The main example of a thing we deploy via the workflow resources is
Ceph. We decided no-opping ceph-ansible for the main
update/upgrade/ffwd upgrade steps is the safest path forward and we'll
update/upgrade Ceph it after the main procedure is finished.
Change-Id: I34c7213ab7b70963ad2e50f7633b665fad70bde5
These tasks would run before any individual server deployments. A
specific use case is for rebooting dpdk/nfv nodes before applying
NetworkDeployment, etc.
Change-Id: I9e410def25184e635568db67149264ac89c999ed
set_fact logs the fact value. In the case of reading the role_data_*
files, this is very verbose as the files can be large. Use no_log: True
to make these tasks less verbose. The content is saved in the
config-download output already, so no useful info is lost.
Change-Id: Ie6f75113194961628a0c9bdfbfbf5d88a18059eb
Closes-Bug: #1760996
Add blank lines between the Ansible tasks and plays in the stack
outputs. This is an improvement in readability for the user.
Change-Id: I52ebd9081cacf213ac29f1d24e73db6ea5cfe33f
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
the upgrade.
Related reviews
I7b19c5299d6d60a96a73cafaf0d7103c3bd7939d tripleo-common
I4227f82168271089ae32cbb1f318d4a84e278cc7 python-tripleoclient
Change-Id: Ib340376ee80ea42a732a51d0c195b048ca0440ac
Add support for the SshKnownHostsDeployment resources to
config-download. Since the deployment resources relied on Heat outputs,
they were not supported with the default handling from tripleo-common
that relies on the group_vars mechanism.
Instead, this patch refactors the templates to add the known hosts
entries as global_vars to deploy_steps_playbook.yaml, and then includes
the new tripleo-ssh-known-hosts role from tripleo-common to apply the
same configuration that the Heat deployment did.
Since these deployments no longer need to be triggered when including
config-download-environment.yaml, a mapping is added that can be
overridden to OS::Heat::None to disable the deployment resources when
using config-download.
The default behavior when not using config-download remains unchanged.
Closes-Bug: #1746336
Change-Id: Ia334fe6adc9a8ab228f75cb1d0c441c1344e2bd9
The resultin pre_upgrade_rolling_steps_playbook will be executed in a
node-by-node rolling fashion at the beginning of major upgrade
workflow (before upgrade_steps_playbook).
The current intended use case is special handling of L3 agent upgrade
when moving Neutron services into containers. Special care needs to be
taken in this case to preserve L3 connectivity of instances (with
regard to dnsmasq and keepalived sub-processes of L3 agent).
The playbook can be run before the main upgrade like this:
openstack overcloud upgrade run --roles overcloud --playbook pre_upgrade_rolling_steps_playbook.yaml
Partial-Bug: #1738768
Change-Id: Icb830f8500bb80fd15036e88fcd314bf2c54445d
Implements: blueprint major-upgrade-workflow
In last step of FFU we need to swich repos before running upgrade.
We do so by introducing post FFU steps and running the switch in
them. We also update heat agents and os-collect-config on nodes.
Change-Id: I649afc6fa384ae21edc5bc917f8bb586350e5d47
This wires in a heat parameter that can be used to disable the
baremetal (Puppet) deployment tasks. Useful for testing
some lightweight/containers only deployments.
Change-Id: I376418c618616b7755fafefa80fea8150cf16b99
Without the extra bool this when block gets evaluated as a string.
Given that it is always present this means enable_debug has been
enabled regardless of the end user setting.
Change-Id: I9f53f3bca4a6862966e558ea20fe001eabda7bcf
Closes-bug: #1754481
Updating OpenStack (within release) means updating ODL from v1 to v1.1.
This is done by "openstack overcloud update" which collects
update_tasks. ODL needs 2 different steps to achieve this
minor update. These are called Level1 and Level2. L1 is
simple - stop ODL, update, start. This is taken care by paunch
and no separate implementation is needed. L2 has extra steps
which are implemented in update_tasks and post_update_tasks.
Updating ODL within the same major release (1->1.1) consists of either
L1 or L2 steps. These steps are decided from ODLUpdateLevel parameter
specified in environments/services-docker/update-odl.yaml.
Upgrading ODL to the next major release (1.1->2) requires
only the L2 steps. These are implemented as upgrade_tasks and
post_upgrade_tasks in https://review.openstack.org/489201.
Steps involved in level 2 update are
1. Block OVS instances to connect to ODL
2. Set ODL upgrade flag to True
3. Start ODL
4. Start Neutron re-sync and wait for it to finish
5. Delete OVS groups and ports
6. Stop OVS
7. Unblock OVS ports
8. Start OVS
9. Unset ODL upgrade flag
These steps are exactly same as upgrade_tasks.
The logic implemented is:
follow upgrade_tasks; when update_level == 2
Change-Id: Ie532800663dd24313a7350b5583a5080ddb796e7
In https://review.openstack.org/#/c/525260/, we moved the creation of
various RoleData driven config files to deploy-steps-tasks.yaml, and to
consume the values from various role_data_* variables that were written in
the inventory (see https://review.openstack.org/#/c/528354/).
However, we were already downloading and saving the RoleData to separate
files via config download. We should consume from those files instead of
the inventory. That has the advantage that one can quickly modify and
iterate on the local files, and have those changes applied. That is
harder to do when these values are in the inventory, and not possible to
do when using dynamic inventory.
Since the tasks will fail trying to read from the files when not using
config-download, conditional local_action tasks that use the stat module
first verify the existence of the files before attempting to read their
contents. If they don't exist, the values fall back to whatever has been
defined by the ansible variable.
Change-Id: Idfdce6f0a778b0a7f2fed17ff56d1a3e451868ab
Closes-Bug: #1749784
We make sure is_bootstrap_node is always set and we reset hiera
hierarchy on first run.
Resolves: rhbz#1535406
Clodes-Bug: #1743740
Change-Id: Ib5cc32b798118c85bf09beab097be2f6eaeb405f
This makes it clearer that the previous task failed, which isn't
immediately evident from the ansible task output due to the failed_when
on those tasks.
Change-Id: I765208d5865f6e5a292e5b52c572e2e79540c663
Closes-Bug: #1748443
This removes most of the Heat driver upgrade workflow, including
the script delivery and stepwise upgrade tasks with invocation
of ansible via heat
For Q upgrades the operator should use
openstack overcloud upgrade --init-upgrade --container-registry-file file
openstack overcloud upgrade --nodes Controller
etc.
Depends-On: I54f8fc57b758e34c620d607be15d2291d545ff6f
Change-Id: I75f087dc456c50327c3b4ad98a1f89a7e012dc68
