Currently, multiple scripts are being stored in
/var/lib/container-config-scripts directory if any of theses scripts
are being used during the update_tasks the content won't be up to
date (or the script will be fully missing if added in a new release),
as the content of this folder is being updated during the deploy tasks
(step 1), which occurs after all the update_tasks.
This patch gathers the tasks responsible for the folder creation and
content update into a new playbook named common_container_config_scripts.yaml,
this way we can reference the tasks from the deploy-tasks step1 playbook
(as it was happening up to now) and invoke them before the update_tasks
playbook gets called.
Change-Id: I2ac6bb98e1d4183327e888240fc8d5a70e0d6fcb
Related-Bug: #1904193
The tripleo_free startegy cuts the run time of composable upgrade.
But as each node gets to different point of code there is need to
remove clear_facts part from tripleo-packages. The clear_facts
applies globaly meaning if messaging node looks for distribution
fact while controller runs clear_facts we will fail. The
clear_facts was added to force ansible to reset the
ansible_python_interpreter. This should be avoided by simply
setting default python by alternatives command and it's irelevant
to any other version than stable/train.
Change-Id: I556327228f23eb5e744b580618fb581a9fd2ce41
This replaces net-config-noop.yaml mappings to OS::Heat::None.
Also removes all unnecessary setting of it in environments as
we map them in overcloud-resource-registry-puppet.j2.yaml.
Normally that should be enough but we override them in so many
places, so there will be some redundancy.
Depends-On: https://review.opendev.org/755275
Change-Id: Ib4d07c835568cb3072770f81a082b5a5e1c790ea
This uses the new ansible module for network configuration
on the nodes. Aso, converts the net-config-multinode.yaml to
use os-net-config.
Next patch in this series would change the NetworkConfig
resource type to OS::Heat::Value and drop run-os-net-config.sh.
Depends-On: https://review.opendev.org/748754
Change-Id: Ie48da5cfffe21eee6060a6d22045d09524283138
We've long supported the ability to deploy rpms or tar.gz to a system
during deployment. It currently is a shell script so let's convert it to
an ansible module.
Change-Id: Id30f89cf261b356f25a93e5df5550e9dfb08f808
Depends-On: https://review.opendev.org/#/c/748757/
The old all nodes validation used a bash script to run some basic ping
tests after the network setup. It used to be a software config but
eventually got baked into the deployment framework. This patch switches
to the ansible role implementation and cleans up the old references to
the old heat resource.
Change-Id: Ia7f055d2c636f950c3fe6d8611834c4ab290f31a
Depends-On: https://review.opendev.org/#/c/747466/
https://review.opendev.org/#/c/749432/ moved network configuration
before the deployments.yaml execution. The deployment.yaml included
legacy executions of deployments (e.g. *PreConfig ExtraConfigPre) which
may be necessary prior to running the network configuration. We shouldn't
change up the ordering of executions where the things being executed may
be dynamic.
Change-Id: I496005ef7f3e75382d2bb20f7c6dc9ed96762695
This seprates the overcloud network configuration as a separate
play and adds a new tag 'network_deploy_steps' so that it can be
executed alone using '--tags network_deploy_steps'.
Change-Id: I96b0d838e79bcaa8b08ffaa2fb745ee7003d1284
Instead of running a giant playbook of external_deploy_tasks, we have
now one playbook per step and per role; which will run individually to
avoid a lot of skipped tasks at each step, and save time during a
deployment or day 2 operation.
Co-Authored-By: Kevin Carter <kecarter@redhat.com>
Change-Id: Iaecd22bc16d1180e2ab8aee5efb8c75ab15f42e5
Move the NetworkConfig tasks to a role maanged in tripleo-ansible.
Change-Id: Ia3fbad9606b18b863a1a81cfe23ff483411d4796
Depends-On: https://review.opendev.org/#/c/744260/
During update we skip a lot tasks because we loop over the same update
step task file, changing the step variable, wasting time and
clobbering logs.
To solve the skipped tasks this, we now loop over the stepX file
generated for update and post update.
Expanding the playbook to import the tasks and setting the step
variable has another benefit. It opens the possibility to use
"start-at-tasks" as everything is imported. Using loop variable and
include_tasks prevented its usage.
Depends-On: https://review.opendev.org/740465
Change-Id: Ib32791d72410766a0b2e2330713120d15dc35f57
Now that the FFU process relies on the upgrade_tasks and deployment
tasts there is no need to keep the old fast_forward_upgrade_tasks.
This patch removes all the fast_forward_upgrade_tasks section from
the services, as well as from the common structures.
Change-Id: I39b8a846145fdc2fb3d0f6853df541c773ee455e
Currently this task definition is causing the following warning to be
thrown at execution time:
[WARNING]: conditional statements should not include jinja2 templating
delimiters such as {{ }} or {% %}. Found: '{{ playbook_dir }}/{{
_task_file_path }}' is exists
There is no reason to be using this conditional with a variable since
this file path is known when we create the playbook. Additionally we
don't need to use the playbook_dir because we're not using it in the
include_tasks. This allows us to specifically express the file that
we're using for these tasks inclusions rather than relying on a
conditional that is not recommended.
Change-Id: I368e99d2384469ca166e2e2b00e8621b7afe72db
We switched to our free version which does work with any_errors_fatal
now so this comment is no longer relevant.
Change-Id: Ifad07edb4496b0e3ea5b34aee3933ece4bb2dfc6
Tolerate failures on all the plays that run on the overcloud and which
potentially run with facts gathering only (no other tasks).
Since they can't apply a strategy, we want to let them fail without
error. In a later play, we have our tripleo strategies which will figure
out if we have reached the maximum of failures that was configured with
MaxFailPercentage.
Change-Id: I43652972494a9ed1f2b8b483fe19e685cbe4da1b
In order to handle percentage failures for tripleo classes we will need
to use a custom strategy to handle the failures. Let's explicitly define
our expected strategies in the playbook so it'll default to linear (the
ansible default) on the host when ansible is invoked but our deployment
tasks will be run as we want them.
Depends-On: https://review.opendev.org/#/c/724766/
Change-Id: Ifaddeccfbb82e03815311ee0b76eb2e2eae282a7
Remove container_startup_configs_tasks.yaml playbook, and some set_fact
tasks that aren't needed anymore; since we now have a module to generate
container startup config files.
Change-Id: I8ebe7f5f52f14a14c3911748b2e2063e0c3ad9ac
The tripleo_free strategy should allow the tasks to run freely for a
given playbook that defines using the tripleo_free strategy. The defaul
strategy is a linear one that will execute each task across all servers
prior to moving to the next task. The tripleo_free strategy will execute
the tasks on servers without syncryonizing the tasks within a given
playbook. Because TripleO uses step concepts in our deployment, we
already have the syncronization points in the main playbook. The outer
playbook should be done linearly but the deployment steps themselves
should be done freely.
The tripleo_free playbook won't stop execution on all hosts if one host
fails or becomes unreachable. It will however end the play exeuction if
any error occurs on any host. This is similar to the deployment failures
we used to have with Heat where a failure on any single node would stop
the deployment at a given deployment step. A future improvement of this
will be to add logic to handle a failure percentage on a given TripleO
role to only stop the playbook if the failure percentage exceeds a
defined amount. Currently any failure will stop a playbook but may not
stop later tasks from executing on the rest of the hosts. We will likely
need to implement a tripleo_linear strategy based on the upstream linear
strategy to understand these failure percentages as well.
NOTE: During the testing of this, we identified two issues with the free
strategy in ansible itself. We will need those fixes landed in the
version of ansible prior to being able to land this.
Depends-On: https://github.com/ansible/ansible/pull/69730
Depends-On: https://github.com/ansible/ansible/pull/69524
Change-Id: Ib4a02a192377aafab5970647d74977cb1189bcae
This change enabled become: true to the deploy step and host prep task
execution. external tasks are still become: false as they are delegated
to localhost and run as the same user running the deployment.
Change-Id: I79631ce0ed450febae96db2f32198e02eb427d91
Related-Bug: #1883609
Once again we're splitting the deployment steps into multiple plays
which causes ansible to artificially stop at the end of each play when
using a free-style strategy. By combining the deploy steps, bootstrap
tasks and common deploy steps, we can run each step to completion in
parallel rather than stopping at each of these for every step. This will
reduce the overall play count to (1*6) instead of (3*6+1)
Change-Id: I986391617231b9dd23aa487d73db490db84f61ce
When executing the deployment_steps_playbook.yaml passing
a specific --tags, it looks like this play gets executed
even though the tag passed in --tags isn't common_roles.
This patch converts the roles: structure into a:
tasks:
- include_role:
which is the prefered way since Ansible 2.4. This way, the
tags work properly and the execution of both roles is skipped
if the tag doesn't match common_roles.
Change-Id: I772ad486ca11525b8756a0b8cac7a5345373a5d3
Closes-Bug: #1885721
Since plays cannot be parallelized with a free-like strategy, we should
have a single play that runs all host prep tasks rather than blocks of
plays for each defined role. By switching to this method we have a
single play that handles the host prep tasks concept that can be run all
at once across a cloud.
Change-Id: I2670840c9beac06f8b8ffc6eaecc88b9119ad298
The scale down actions appear to fail under newer versions of ansible if
the nodes are unavailable. In the logs we see:
[WARNING]: Found variable using reserved name: ignore_unreachable
This change renames our variable to not collide with ignore_unreachable
Change-Id: Ida54f59fc1415122241493c02a0fc764d09ae6c1
We already do this in the time configuration and it is no longer a
configurable item due to containers. Let's stop doing this in the all
nodes validation and let the time configuration handle the failure
messaging.
Change-Id: Ib0abcbd25117ecd587f4a92698746e5e256e6e8e
Paunch was deprecated in Ussuri and is now being retired, to be fully
replaced by the new tripleo-ansible role, tripleo_container_manage.
This patch:
- Removes common/container-puppet.py (was only useful when paunch is
enabled, since that script was converted to container_puppet_config
Ansible module in tripleo-ansible).
- Update all comments refering to paunch, and replace by
tripleo_container_manage.
- Deprecate EnablePaunch parameter.
- Remove paunch as python dependencies.
Depends-On: https://review.opendev.org/#/c/731545/
Change-Id: I9294677fa18a7efc61898a25103414c8191d8805
The playbook fails when removing unreachable nodes from deployment with
`openstack overcloud delete node`. Some `ignore_unreachable: true` are
missing. Also, one cannot use `any_errors_fatal: true` when ignoring
unreachable nodes, otherwise the playbook execution will stop after the
current task.
Change-Id: Ibcb84e58bac1975490df281c0de950cdf74337b2
When refactoring deploy-steps to add a common playbook [0] it seems that
the post_upgrade_steps_playbook block was missed. As a consequence, when
executing the post_upgrade_tasks some of the common Ansible variables
are not available.
[0] - Ib00e8aa9f7d06517290543a8aaf8a2527969bd3c
Change-Id: I04704a14a8b932e21d21348e10014c707a87eeeb
Closes-Bug: #1875579
Since I2cc721676005536b14995980f7a042991c92adcc we can no longer assume that
an overcloud group exists in the inventory. Default to the <stack_name> group
instead.
Change-Id: I895e315ff3984ebf1806288a8275a8b0d74bef49
Closes-bug: #1875429
Currently if you have selinux enabled on the undercloud but disable it
for the overcloud, selinux is disabled on the undercloud during the
deployment. This can be resolved by only managing the selinux setting
for the deployment target hosts rather than the all.
Change-Id: I94b81ea0b954cdba7704720a145b752fa58d4308
Closes-Bug: #1874828
This one toggles the no_log parameter. Directly related to #1873770 in
order to allow a deeper debug within CI.
Change-Id: I27f677467263c0e6cc78d775edff55b3811fec1f
Related-Bug: #1873770
This simplifies all the split/join transformations and improves the
memory footprint to a reduced list of unique entries for
HostsEntryValue (originally required for storing the ultimate data for
hosts entries in a form of a quite long single-line string value).
That improves the hosts entries processing for large scale deployments
and removes possible limitations to the sizes of strings.
Closes-bug: #1869375
Change-Id: I5ac498621e9e3c49def565744a7b521cb2cc5c25
Signed-off-by: Bogdan Dobrelya <bdobreli@redhat.com>
Hosts entries are used to be configured via tripleo_ansible's
tripleo_hosts_entries.
Ifd4bc4ce5618587c341ecbf37f82777ae6fc2f4a removed the use
of WRITE_HOSTS, which currently makes hosts-config.yaml "headless" and
taking no real data for the hosts-config.sh template that generates
outputs for OS::TripleO::Hosts::SoftwareConfig.
Also I606e0f27f9f9ae9d85bc0fc653f8985eb734d004 removed the use of
HOST_ENTRY, which makes the hosts-config.sh taking an empty value for
it.
Probably that all makes it safe now to remove any use of
hosts-config.sh and hosts-config.yaml and corresponding
OS::TripleO::Hosts::SoftwareConfig completely.
Change-Id: Id04767ae0c32caf62271cf564608350974fefd1b
Signed-off-by: Bogdan Dobrelya <bdobreli@redhat.com>
Many of the lines are difficult to grasp due to the crazy
quotation and concatenation implemented to get the desired
result from generating playbooks via a jinja template.
We can make it easier to read and easier to understand by
using the jinja raw tag instead. This eases the maintenace
burden on us all and helps us sleep better at night.
Change-Id: I82c4de4a63817707a2b0ed0ced827be37c0d0463
Jose Luis Franco Arza