openstack/kolla-ansible.git/ansible/roles/rabbitmq/tasks/precheck.yml, branch stable/2026.1

rabbitmq: fix precheck missing backend TLS cert fallback

2026-09-08T13:48:29+00:00

service-cert-copy falls back to kolla_tls_backend_cert/key when no rabbitmq-specific cert is found, but the precheck did not check for this path, causing a false failure when relying on the shared backend certificate. Closes-Bug: #2166283 Change-Id: I75d4b33fc893bcf0793c1280981574bcdf3f3002 Signed-off-by: fprzewozn (cherry picked from commit a54ad717f08a8258424004e6224a36ea561393d2)

Make RabbitMQ stream retention policy configurable

2026-04-24T08:21:14+00:00

When fanout queues are set to be RabbitMQ stream, number of ready messages in stream queues grow large. This is because retention policy of stream is only applied when stream segments hit the maximum size. This change make the maximum size of RabbitMQ stream segment and the retention time configurable by new variables ``rabbitmq_stream_max_segment_size_bytes`` and ``rabbitmq_stream_segment_max_age`` respectively. NOTE: These are only applied when ``om_enable_rabbitmq_stream_fanout`` is set to ``true``. Change-Id: Iade5e525f0de8981a0e03e3340ad7552c2f40121 Signed-off-by: Seunghun Lee

ansible-lint: Fix fqcn[actions-core] for rabbitmq

2026-03-23T17:05:12+00:00

Change-Id: I1285f9c00829a7d64851c16a7222985eabdc06ef Signed-off-by: Michal Nasiadka

ansible-lint: fix unnamed-task in rabbitmq

2025-12-10T21:19:49+00:00

Change-Id: I267662b8ecc0d8a833d92983f40de1f5c78d1bcd Signed-off-by: Bertrand Lanson

ansible-lint: Remove key-order[task] exclude

2025-11-17T10:53:10+00:00

Change-Id: I77cce57f3f2b05455e8bd4e7093081ef4ed25d59 Signed-off-by: Michal Nasiadka

Don't allow quorum queues to be disabled

2025-04-09T14:20:59+00:00

We will be upgrading RabbitMQ to version 4.0 in Epoxy. This will not work without quorum queues being enabled. Change-Id: Ic6ad64bf8c62bbff175e15029eb121814032c40e

Remove om_enable_rabbitmq_high_availability

2025-04-03T08:02:34+00:00

We're going to upgrade RabbitMQ to 4.0, so this option will not longer be supported. Change-Id: Ide75a8c9086798bf4bdf5bc02d4a1be17017884f

rabbitmq: Add support for using stream queues for fanout

2025-04-02T10:59:07+00:00

The global configuration of rabbit_qos_prefetch_count = 1 in oslo.messaging is a deliberate choice that balances compatibility, fairness, and reliability across all OpenStack services. While some services (particularly those using quorum queues) could theoretically benefit from a higher or even unlimited prefetch count for performance reasons, this is not universally safe. Specifically, RabbitMQ stream queues - which are used in certain OpenStack components do not support a prefetch_count of 0. Setting this value to 0 would result in runtime errors or stalls, as the stream protocol requires a positive credit window to function properly. Oslo.messaging enforces this by raising an error if prefetch_count = 0 is set while using stream queues. A value of 1 is the lowest legal and universally compatible setting. It works safely with both stream and quorum queues. It also improves fairness in message distribution across worker processes. In distributed services like Nova, Neutron, or Cinder, this helps avoid uneven load where one worker might prefetch many messages while others remain idle. A low prefetch count ensures that messages are pulled only when the worker is ready, promoting better load balancing and more predictable performance. Although a higher prefetch value could increase throughput in certain scenarios, it comes at the cost of memory usage, risk of overloading specific nodes, and potential starvation of others. Until oslo.messaging supports queue-type-specific or per-service tuning, the value of 1 remains the safest and most predictable option that works well in mixed OpenStack environments. In summary, rabbit_qos_prefetch_count = 1 is not about optimizing raw throughput for any one service, but about ensuring stable, fair, and reliable behavior across all services that rely on oslo.messaging, regardless of the queue type or broker backend used. Change-Id: I541f704bfa2e98068096331afbdb591659cbc40b

Rabbitmq: enable quorum for transient queues

2025-03-27T08:35:35+00:00

This helps to improve the reliability of openstack services when a rabbitmq node has issues. See also: https://bugs.launchpad.net/oslo.messaging/+bug/2031497 Adjust the upgrade tests similar to what was done during the introduction of quorum queues in I6c033d460a5c9b93c346e9e47e93b159d3c27830 Closes-Bug: #2078339 Partial-Bug: #2077448 Depends-On: https://review.opendev.org/c/openstack/oslo.messaging/+/888479 Depends-On: https://review.opendev.org/c/openstack/kolla-ansible/+/924623 Signed-off-by: Sven Kieske Change-Id: Idb8a8d2e560206f7697c0771c9ae3913268fa6dd

Add oslo.messaging Queue Manager

2025-03-24T09:17:25+00:00

Adds the variable ``om_enable_queue_manager`` to configure enabling oslo.messaging Queue Manager for all services which use RabbitMQ. This is enabled by default. This is required before we can move away from transient queues (``rabbit_transient_quorum_queue``) as Queue Manager is needed to avoid consuming all erlang atoms after some time. It is also a useful feature for debugging, as queues are now named with hostnames and services included. Also setting ``lock_path`` and mounting ``dev/shm`` is dependent on ``om_enable_queue_manager``, these are now enabled too. This will allow us to backport these features to Caracal and Dalamation without enforcing the changes right away. Why is -t added for exec commands? When using Podman, behavior differs from Docker regarding exec commands. If -t (which allocates a pseudo-terminal) is not used, the process runs as a child of podman exec without a PTY. This causes Python inside the container to assign PGID=0 because the pseudo-terminal is missing, leading to issues with non-existent paths like /proc/0/.... Adding -t ensures proper PGID assignment, preventing these issues and ensuring consistent behavior across Docker and Podman. Side-notes: The quorum queue precheck needed to be updated as queue manager puts "_fanout" on the end of the name instead. We need to override the ``[oslo_messaging_rabbit] processname`` for services running udner wsgi, as they will otherwise all use the same processname ``mod_wsgi``. This will cause Permission Errors trying to access the same file in shared memory as services run with different users. Change-Id: Iae5f268e778fbbd2b744dc71a84253ec9e758a99