This change breaks the deploy-steps monster playbook into isolated playbook
files allowing us to use the deploy-steps entrypoint as a playbook router.
With this change we'll be able to further optimise our playbook processes
in isolation and begin exploring different methods of deployment for parts
of our stack. Additionally this change will make it possible for advanced
users to run playbooks as needed, without having to run everything from
top to bottom.
Change-Id: I34bb41e63ccc65ae47999758ab7ce8a6120ef0a4
Signed-off-by: Kevin Carter <kecarter@redhat.com>
This change updates the artifact module usage to leverage
our action plugin. Without this change any usage of deployed
artifacts is broken.
> "Unsupported parameters for (tripleo_deploy_artifacts)
module: artifact_paths Supported parameters include:
artifact_urls"
This change resolves the above error.
Change-Id: I792f453d4f84c3b572fe98929676b624675c0aee
Signed-off-by: Kevin Carter <kecarter@redhat.com>
This simplifies the ServiceNetMap/VipSubnetMap interfaces
to use parameter merge strategy and removes the *Defaults
interfaces.
Change-Id: Ic73628a596e9051b5c02435b712643f9ef7425e3
We don't need to add these tasks for roles with zero
count. We probably should not create service chains for
roles with zero count, but that's a bigger change.
Change-Id: I41c6b4799eef7940b12811468dcc48e7b6fa543b
Moving the network and port management for OVN
bridge MAC addresses to ansible.
Removes the heat resources, and adds an external
deploy task at step 0 in the ovn controller service
templates which uses the 'tripleo_ovn_mac_addresses'
ansible module to create/remove OVN mac address ports.
Adds parameter role_specific OVNStaticBridgeMacMappings,
parameter that can be used to set static bridge mac
mappings. When this is set no neutron resources will be
created by the tripleo_ovn_mac_addresses ansible module.
OVNStaticBridgeMacMappings must be used for standalone
deployments.
Implements: blueprint network-data-v2-port
Depends-On: https://review.opendev.org/782891
Depends-On: https://review.opendev.org/783137
Change-Id: I6ce29d2908e76044c55eb96d0d3779fe67ba9169
Following the refactor from Idf004f7a13544dfc1a8a6da033debd1a4f8b96e7
the operations needed to get the container configuration where removed
from the step1 file.
We need to re-include them explicitly during update so that new
changes get taken into account.
In the deployment we have this sequence (keeping only those common
with update):
- step-0
- host-prep-task
- common container setup
- common deploy steps tasks 1-5
We mimic this sequence in update by placing common container setup
before the common deploy steps tasks 1-5.
Change-Id: I5df88cf9d84f5fecb50b0c602b7923027d5f12b0
Closes-Bug: 1926281
Make it aligned with the upgrade tasks, what uses become as well
Change-Id: I58da2c214c5a9cf013bc7719649e0d0d4f3a6f74
Signed-off-by: Bogdan Dobrelya <bdobreli@redhat.com>
With this change a Heat resource is no longer used to
create an undercloud neutron API port resource for the
redis and ovn_dbs service virtual IPs. Instead an
external deploy task at step 0 in the individual service
template uses the "tripleo_service_vip" ansible module
to mange a neutron API port resource for each service.
The interfaces to control the IP address and service
network (RedisVirtualFixedIPs, OVNDBsVirtualFixedIPs
and ServiceNetMap) remains the same.
It is also possible to include the 'use_neutron' boolean
in the FixedIPs parameter to instruct the ansible module
not to create a neutron API resource, and simply "echo"
the ip_address given in the FixedIPs parameter. For
example:
RedisVirtualFixedIPs:
- ip_address: 1.0.0.5
use_neutron: false
Alternatively the fixed-ips can be set using the
'ServiceVips' parameter, like this:
ServiceVips:
redis: 1.0.0.5
ovs_dbs: 1.0.0.6
NOTE: If the neutron service is not available the
tripleo_service_vip ansible module will "echo"
the IP provided in %service%VirtualFixedIPs.
Related: blueprint network-data-v2-ports
Depends-On: https://review.opendev.org/777307
Depends-On: https://review.opendev.org/779883
Change-Id: I4794418546363888e7a555a16b45b7a4417f1ef8
Let's introduce a new set of tasks that will be called after all the
groundwork to run containers has been run (so after podman's
host_prep_tasks, after the container_setup tasks but before any
deployment step or external deployment step).
Change-Id: If3c74703a684fbd5a815e073cc9da34e9ad672e8
With I57047682cfa82ba6ca4affff54fab5216e9ba51c Heat has added
a new template version for wallaby. This would allow us to use
2-argument variant of the ``if`` function that would allow for
e.g. conditional definition of resource properties and help
cleanup templates. If only two arguments are passed to ``if``
function, the entire enclosing item is removed when the condition
is false.
Change-Id: I25f981b60c6a66b39919adc38c02a051b6c51269
And move it into its own play called 'Overcloud container setup tasks'
This set of tasks covers creating kolla files and
container-startup-config files.
It makes more sense to split them out of the deployment steps as they
need to be run before any deployment step task and this makes it more
explicit.
This change is needed in order to support a new upcoming set of tasks
pre_deployment_setup_tasks that can spawn containers even before
any deployment tasks or external deployment task.
Change-Id: Idf004f7a13544dfc1a8a6da033debd1a4f8b96e7
- enable run of ansible-lint, with a temporary set of excludes
- fixes two problems reported by ansible-linter
Change-Id: Ibbe23db8fd5ac1008109f50f514df96686b0fa19
Bug: #1921409
Until now, we only relied on the ":z" flag in order to set container
volumes label to container_file_t.
While it works fine, it has multiple issues:
- if an operator runs a restorecon, it might break the container service
- if an SELinux related package is updated, it might reset the label,
and break the container service
- it requires a container stop&start to reset the label to the expected
value
- in case of deep tree or huge amount of file, relabelling takes time
This change ensures the system sets the expected context on the specific
locations, instead of following the content of selinux-policy-targeted
rulesets.
It has an equivalent for some locations in tripleo-ansible repository:
https://review.opendev.org/c/openstack/tripleo-ansible/+/782393
Note about swift locations:
Since openstack-selinux already sets fcontext rules for, at least, once
swift location, we can't override it here. The following
openstack-selinux patch is being pushed in order to work around this
specific case:
https://github.com/redhat-openstack/openstack-selinux/pull/73
Change-Id: Icb7f58004e281b42141c70a9a4895905dc32b45d
Resolves: rhbz#1941922
This change adds an artifact push task to deployments, which helps
support operators to ensure they've a better overall user experience
without needing to deploy an http server or running Swift on the
undercloud.
Depends-On: I5d18cf334c1bc4011db968fbeb4f9e41869611cd
Change-Id: I7bef7c4c7613a2475784dde135d71232b412d79f
Signed-off-by: Kevin Carter <kecarter@redhat.com>
When we disable inject facts by default, there were some additional
roles that we missed (ipaclient). We can just set the legacy facts to
prevent issues with missing distribution var updates.
Change-Id: Ib488a6573c035fc8288a4b24461af56d40416c5d
Related-Bug: #1919064
This patch exposes the net_cidr_map variable so that tasks can
access the list of CIDRs that are valid for a network as opposed
to attempting to build the CIDRs from the network definitions.
In spine-leaf or edge use cases the networks may have multiple
subnets assigned to a given network.
The new Unbound service will use these maps to build lists of
CIDRs allowed to make queries.
Change-Id: I6004519e8b2317d19356c4a2b8bea416b4d94c22
In order to ANSIBLE_INJECT_FACT_VARS=False we have to use ansible_facts
instead of ansible_* vars. This change switches our distribution and
hostname related items to use ansible_facts instead.
Change-Id: I49a2c42dcbb74671834f312798367f411c819813
Related-Bug: #1915761
Import tasks causes the tasks always to be pulled in and just skipped at
run time. This is terribly slow with more roles even when not running
against those hosts. A similar effort was applied to the update process
I2eab008ca27546acbd2b1275f07bcca0b84b858c which should also be used
here.
Change-Id: Ibd9bb9f8a4c6a7ce3c6ebd11ce5cf444dde57c33
Related-Bug: #1915761
This change switches from using service facts to using systemctl
commands to do service checks. This is done to reduce the amount of
memory used as part of the deployment.
Change-Id: I0cd5b24933e50680baefd055d6e68e277ab09315
Related-Bug: #1915761
This was mainly there as an legacy interface which was
for internal use. Now that we pull the passwords from
the existing environment and don't use it, we can drop
this.
Reduces a number of heat resources.
Change-Id: If83d0f3d72a229d737a45b2fd37507dc11a04649
This change restores the PreNetworkConfig resources, so that we migrate
back ExtraCnfigPre and NodeExtraConfig from pre network configurations
to post network configurations, to be consistent with older version
depending on Heat software deployments instead of config download.
Depends-on: https://review.opendev.org/772303
Closes-Bug: #1907214
Change-Id: I96e7e4c570839cfba6011788464d8e93925b2f01
The "Overcloud common bootstrap tasks for step 1" setup pulls in the
tasks from the following file:
common_deploy_steps_tasks_step_1: {get_file: deploy-steps-tasks-step-1.yaml}
Now in that file we mainly do the following tasks:
- Set up the /var/lib/{tripleo-config,container-puppet,kolla} folders
- Write the container config json files
- Set up some puppet folders
- Write puppet step_config manifestes
Not only it makes sense to have these preparation steps before the
deployment steps, even at step1, but it also is strictly needed for
the Frr/Bgp service. The reason for that is that Frr runs containerized
and needs to start at deploy_step 1, so that traffic to the other bgp nodes
is working before step_config step 1 which contains the puppet
invocation to set up the cluster.
In particular the frr/bgp container needs to be started during
deployment step1 and to do so we need the kolla files and the other
container startup files to be set up before we invoke podman.
I could not figure out from the git history as to why this was not done
in the first place, it seems to not have been done on purpose.
So I did some extra testing to make sure nothing got broken by this:
1) Tested a composable control plane largish env with this patch only (train)
2) Tested a minor updated process on (1)
3) Tested a redeploy on (1)
4) Tested an FFU upgrade from queens to train with this change applied
(3xctrl + 2xcmp)
5) Tested a BGP deployment spread over 3 racks in a spine/leaf
configuration (~a dozen of deployments)
Change-Id: I0e6594bfd1ff2e27bb4917c157f163643a811ca6
When we moved the network deployment to free, we can hit a race
condition where some nodes are being configured prior to the controllers
being ready. This can lead to the basic network validation failing. We
can deal with this by moving the validation to it's own play so that we
ensure all network configurations have occurred prior to to checking
that nodes can ping the controllers.
Change-Id: I48665379a87e701633be1bcc90bd8be1cc75c513
Closes-Bug: #1913725
With this new switch we can opt-out enforcement of the subscription
check for some composed role. This is mainly useful for composed Ceph
which have different constraint than other Openstack roles.
Closes-Bug: #1912512
Depends-On: https://review.opendev.org/c/openstack/tripleo-ansible/+/771671
Change-Id: I46529ccab6c197da4885950282eb6731e28573d6
When we clear the cached facts with unreachable nodes, we attempt to
gather facts by default. This can cause the node to be skipped for every
future playbook. This ends up bypassing all our failure percentage
logic.
Change-Id: Ie240877496b73a37f553a84af47dfebdbaf899e5
Related-Bug: 1908573
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
Sometimes cloud-init does not finish before we start applying
configs with ansible/puppet and can lead to issues. This would
ensure that cloud-init has finished before ansible/puppet
configs.
With os-collect-config we used to ensure that with:
$ sudo cat /usr/lib/systemd/system/os-collect-config.service
[Unit]
Description=Collect metadata and run hook commands.
After=cloud-final.service
Before=crond.service
With baremetal provisioning after config-drive support, this
would also be useful when firstboot config is used.
Change-Id: I35c7c1610af08b33497f43090761aaa55d3a9efc
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
Sagi Shnaidman