In order to honour configured max number of attempts
it has to be presented in nova.conf inside of
nova_conductor container, otherwise the default value
of 3 will be used

Closes-Bug: #2003587
Change-Id: I928af332b8658223444594f96417830233057284

Change-Id: Ib69642056e760bad0e4ea13576502f0e08115259

Nova changes to RBAC [1] are breaking Kolla Ansible and causing most CI
jobs to fail. Disable these changes until we can adapt.

[1] https://review.opendev.org/c/openstack/nova/+/866218

Change-Id: I506697d2b374e74a6b066c788bd2d61edc8d4876

Change-Id: Iac88aece372102835b03f7e0e5684d0285857e97

It's not supported in ansible-collection-kolla since Zed release,
and Kolla executed Kolla-Ansible CI jobs fail on it, because
they build images.

Change-Id: Ib0358f780a77af152225761a4aa3b6acbea2eeaf

According to the code, docs and oslo-config-validator, this
configuration option is not supported.

Change-Id: I34410e5267d527ec629748f35771f227183810b6

This option has never been supported by Glance.

Change-Id: I08113292ec862d6ef72b870dcf12577bf02d3771

Makes sure the facts required to generate octavia.conf are available
when using genconfig.

This change also ensures that the necessary tasks run when using Ansible
check mode.

Closes-Bug: #1987299
Change-Id: Ib8fbee2d3abdcfd2eae0f9b3e9b69eeb0e3086e0

A combination of durable queues and classic queue mirroring can be used
to provide high availability of RabbitMQ. However, these options should
only be used together, otherwise the system will become unstable. Using
the flag ``om_enable_rabbitmq_high_availability`` will either enable
both options at once, or neither of them.

There are some queues that should not be mirrored:
* ``reply`` queues (these have a single consumer and TTL policy)
* ``fanout`` queues (these have a TTL policy)
* ``amq`` queues (these are auto-delete queues, with a single consumer)
An exclusionary pattern is used in the classic mirroring policy. This
pattern is ``^(?!(amq\\.)|(.*_fanout_)|(reply_)).*``

Change-Id: I51c8023b260eb40b2eaa91bd276b46890c215c25

We've noticed cases where nodepool.private_ipv4 is empty, probably
caused by [1] or a change in nodepool provider configuration.

[1]: https://review.opendev.org/c/zuul/nodepool/+/862522

Change-Id: Ibeca7d99571d9f6d4d1b90277121d685d73c9a59

When running in check mode, some prechecks previously failed because
they use the command module which is silently not run in check mode.
Other prechecks were not running correctly in check mode due to e.g.
looking for a string in empty command output or not querying which
containers are running.

This change fixes these issues.

Closes-Bug: #2002657
Change-Id: I5219cb42c48d5444943a2d48106dc338aa08fa7c

Change-Id: I110c642da925a5f6b3bd071e7844c20fda673c66

Prevent the haproxy-config role from attempting to modify firewalld when
running kolla-ansible genconfig.

Closes-Bug: #2002522
Change-Id: Ie8a524cc944aa8cb9cf0999b1b8da79f30b40092

Change-Id: Ie9832bd9cae497e7dbd2a03661361c125d8ec15a

Change-Id: I8855bd60c2fd77f33fb55d4123131a94327bd166

The ``[oslo_messaging_rabbit] heartbeat_in_pthread`` config option
is set to ``true`` for wsgi applications to allow the RabbitMQ
heartbeats to function. For non-wsgi applications it is set to ``false``
as it may otherwise break the service [1].

[1] https://docs.openstack.org/releasenotes/oslo.messaging/zed.html#upgrade-notes

Change-Id: Id89bd6158aff42d59040674308a8672c358ccb3c

Depends-On: https://review.opendev.org/866943
Change-Id: Ib3caf7378c1d5e2e9cfe04e36797bd827e99d6c5

Change-Id: I40021caf3f94e718ea42d9ef77e5d9c77c3133de

Setting ovn-monitor-all to 'true' will configure
ovn-controller to monitor all OVS database records
unconditionally. That will release some CPU resource
from OVS Southbound DB but will increase number of events
coming to ovn-controller.

Default value is 'false'.

Change-Id: I291e166013d8c88f00e84ceaf308251c352c9a79

ovn-controller should be deployed first according to OVN upgrade guide.
Since we are getting newer OVN/OVS versions from RDO/Ubuntu in a cycle,
let's apply that to deployment.

Closes-Bug: #1979329

Change-Id: I017aec611a057db1634cfc2634164b21cb210193

Regularly, we experience issues in Kolla Ansible deployments because we
use wrong options in OpenStack configuration files. This is because
OpenStack services ignore unknown options. We also need to keep on top
of deprecated options that may be removed in the future. Integrating
oslo-config-validator into Kolla Ansible will greatly help.

Adds a shared role to run oslo-config-validator on each service. Takes
into account that services have multiple containers, and these may also
use multiple config files. Service roles are extended to use this shared
role. Executed with the new command ``kolla-ansible validate-config``.

Change-Id: Ic10b410fc115646d96d2ce39d9618e7c46cb3fbc