... because kolla_start fails to start with the following error if
that environment parameter is not defined.
ERROR:__main__:InvalidConfig: KOLLA_CONFIG_STRATEGY is not set properly
Change-Id: I7cdf127b495c4d9f415a703fc8b7954a3f5b53fe
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
It appeary running the tmpwatch from the cron.daily location isn't
possible: the way cron/anacron is running things appears to break
SELinux context at some point, leading to SELinux denials caused by a
weird need for dac_override.
In order to NOT allow this dac_override (security hazard), and after
extensive testing, it seems it's better to push the job directly in
root's crontab.
Change-Id: Ib7e1d47fe7cffa2bd2ed1d72d94e4f380162f10a
Closes-Bug: #1922002
Resolves: rhbz#1944466
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
This changes all these parameters as heat would correctly
parse all values. Also, drops all yaql shenanigans
used for their handling and heat conditions.
Also fixes wrong usage of non-existent NeutronWrapperDebug
parameter in ovn-metadata-container-puppet.yaml.
We had converted all ``Debug`` parameters to boolean with
Ib6c3969d4dd75d5fb2cc274266c060acff8d5571.
Change-Id: Ia2bffffde34aa248a4cc60c3895464f1f9d1ded2
We see many issues in CI due to the missing hdd device class.
This is something that can be related to the fact that only
1 OSD in this job is built on top of a loop device.
For this reason, and in order to keep the CI healthy, it's
safe removing the device classes coverage.
In addition, since there is only 1 osd, add and configure
tiering in this context makes no sense.
Change-Id: I4638b9badd17a7a75642895623a63753534fd341
- removes duplicate keys from yaml files by assuming that the last
one was the desired one (matches current loader behavior)
- prevent regressions by activating yaml lint rule that detects them
(yaml skip was silencing all yaml checks, so the long list seen
is in fact shorter than just 'yaml')
- includes sorting of some of the keys, was needed in order to spot
the duplicates.
Change-Id: Idf5c0041a0c6d3ed7d5d49fb68be856719916663
We do not need to add an if: internal_tls_enabled in a number of
ansible tasks. enabled_internal_tls is already defined as an ansible
fact in common/deploy-steps.j2:
enable_internal_tls: {get_param: EnableInternalTLS}
So when the service uses the enable_internal_tls condition and it points
to the EnableInternalTLS param, we can just use the ansible fact
directly. Note that if the enable_internal_tls condition points to
something else than the mere EnableInternalTLS we may not do this
cleanup.
Change-Id: Idb07cbc8fc3a4d73ff52c54d869310fd6c49b502