Adds a precheck to fail if non-quorum queues are found in RabbitMQ.

Currently excludes fanout and reply queues, pending support in
oslo.messaging [1].

[1]: https://review.opendev.org/c/openstack/oslo.messaging/+/888479

Closes-Bug: #2045887
Change-Id: Ibafdcd58618d97251a3405ef9332022d4d930e2b

Change-Id: I373f6d13809674c521155ca51962785a8b1ac598

Starting with ansible-core 2.13, list concatenation format is changed
and does not support concatenation operations outside of the jinja template.

The format change:

  "[1] + {{ [2] }}" -> "{{ [1] + [2] }}"

This affects the horizon role that iterates over existing policy files to
override and concatenate them into a single variable.

Co-Authored-By: Dr. Jens Harbott <harbott@osism.tech>

Closes-Bug: #2045660
Change-Id: I91a2101ff26cb8568f4615b4cdca52dcf09e6978

This allows us to continue execution until a certain proportion of hosts
to fail. This can be useful at scale, where failures are common, and
restarting a deployment is time-consuming.

The default max failure percentage is 100, keeping the default
behaviour. A global max failure percentage may be set via
kolla_max_fail_percentage, and individual services may define a max
failure percentage via <service>_max_fail_percentage.

Note that all hosts in the inventory must be reachable for fact
gathering, even those not included in a --limit.

Closes-Bug: #1833737
Change-Id: I808474a75c0f0e8b539dc0421374b06cea44be4f

Add file to the reno documentation build to show release notes for
stable/2023.2.

Use pbr instruction to increment the minor version number
automatically so that master versions are higher than the versions on
stable/2023.2.

Sem-Ver: feature
Change-Id: I96140b1e3be06b60909f3eed739f1a944e119c7e

If a file {{ node_custom_config }}/magnum/kubeconfig exists, it is
copied to /var/lib/magnum/.kube/config in all Magnum Service Containers.
At this location, the vexxhost/magnum-cluster-api will loo for the Kubeconfig
configuration file to control the Cluster API Control Plane. If the
vexxhost/magnum-cluster-api is installed in the Magnum container images,
control of a cluster API control plane can then take place via the Magnum API.

Depends-On: https://review.opendev.org/c/openstack/kolla/+/902101
Change-Id: I986c5192fe96b9c480a2d8fa87d719a50ce78186

podman_image_info returns Config dict, not ContainerConfig.

Change-Id: I9f813c90b42246c4835d7d7b18476a021d80548b

Change-Id: I54f94c383ae5a1185b364495422e1ab79cbd1afb

This implements a global toggle `om_enable_rabbitmq_quorum_queues`
to enable quorum queues for each service in RabbitMQ, similar to
what was done for HA[0].

Quorum Queues are enabled by default.

Quorum queues are more reliable, safer, simpler and faster than
replicated mirrored classic queues[1].

Mirrored classic queues are deprecated and scheduled for removal
in RabbitMQ 4.0[2].

Notice, that we do not need a new policy in the RabbitMQ definitions
template, because their usage is enabled on the client side and can't
be set using a policy[3].

Notice also, that quorum queues are not yet enabled in oslo.messaging
for the usage of reply_ and fanout_ queues (transient queues).
This will change once[4] is merged.

[0]: https://review.opendev.org/c/openstack/kolla-ansible/+/867771
[1]: https://www.rabbitmq.com/quorum-queues.html
[2]: https://blog.rabbitmq.com/posts/2021/08/4.0-deprecation-announcements/
[3]: https://www.rabbitmq.com/quorum-queues.html#declaring
[4]: https://review.opendev.org/c/openstack/oslo.messaging/+/888479



Signed-off-by: Sven Kieske <kieske@osism.tech>
Change-Id: I6c033d460a5c9b93c346e9e47e93b159d3c27830

* Updates etcd to v3.4
* Updated the config to use v3.4's logging mechanism
* Deprecated etcd CA parameters aren't used, so we are not affected
  by their removal.
* Note that we are not currently guarding against skip-version updates for
  etcd.

Notable non-voting jobs exercising some of this:
* kolla-ansible-ubuntu-upgrade-cephadm (cinder->tooz->etcd3gw->etcd)
* kolla-ansible-ubuntu-zun (see
  https://review.opendev.org/c/openstack/openstack-ansible/+/883194 )

Depends-On: https://review.opendev.org/c/openstack/kolla/+/890464
Change-Id: I086e7bbc7db64421445731a533265e7056fbdb43

* etcd service containers usually have a set of
  environment parameters required to boot the container.
* The short-lived etcd bootstrap containers pass extra
  ETCD_INITIAL_* environment variables, but still need to
  pass the ones that the service containers use.
* This uses ansible's `combine` filter to cut down on the
  duplication.
* This is intended to be just a straightforward refactor.

Change-Id: I04e95f92a8f365553afd618d58b99de595d48312

Change-Id: Ie3963f5ed20f7fb61ef2e03f0cf12a4ea1c87c9c

This dependency was added to podman-py in version 4.8.0, but not added
properly to their requirements. Install it explicitly for our tox
and integration testing as a workaround.

[0] https://github.com/containers/podman-py/issues/350

Change-Id: I61a5fdfc4e505f2577185f0c0f1297cf2709be2c

Just some minor formatting and wording updates

Change-Id: Ia42944512f8d14a1993bd4ae3d09f0f2ab431322

Change-Id: Ia1de6d9452e2c900169e9b4ccb7dfc1280283909

This commit addresses a few shortcomings in the etcd service:
  * Adding or removing etcd nodes required manual intervention.

  * The etcd service would have brief outages during upgrades or
    reconfigures because restarts weren't always serialised.

This makes the etcd service follow a similar pattern to mariadb:
  * There is now a distiction between bootstrapping the cluster
    and adding / removing another member.

  * This more closely follows etcd's upstream bootstrapping
    guidelines.

  * The etcd role now serialises restarts internally so the
    kolla_serial pattern is no longer appropriate (or necessary).

This does not remove the need for manual intervention in all
failure modes: the documentation has been updated to address the
most common issues.

Note that there's repetition in the container specifications: this
is somewhat deliberate. In a future cleanup, it's intended to reduce
the duplication.

Change-Id: I39829ba0c5894f8e549f9b83b416e6db4fafd96f

Depends-On: https://review.opendev.org/c/openstack/kolla/+/901508
Change-Id: I8c7d3de95d0f1f8e57a993b8c3417d90459e19be

Like other WSGI services in Kolla Ansible, the Horizon WSGI application
handles log output via the `wsgi.errors` object. See [1] for further
information. The problem is that this log output is written to a file called
`horizon.log`, causing it to processed as an 'Oslo log' in the Fluentd
processing pipeline. Since the log format doesn't match the expected format,
this results in parsing errors.

This fix renames the log file and adjusts the format to match other WSGI
applications. The logs are then processed in the same way as other WSGI
application logs, resolving the issue.

[1] https://modwsgi.readthedocs.io/en/master/user-guides/debugging-techniques.html

Change-Id: I93777d1c53920f5470c78356e6b3a4064fbe04b4
Closes-Bug: #1898174

This reverts commit b86c304a.

Reason for revert: We want to enable Quorum Queues by default in Caracal, without requiring two queue migrations between releases. See etherpad for details: https://etherpad.opendev.org/p/kolla-ansible-rmq-quorum-queues-proposal

Change-Id: Ia19ab97f538125475297976347c5da332a7fdda7

Change-Id: Id6ca24c058fabf0c68bcb5b6d1e58175aaf531eb