- Sep 18, 2024
-
-
Matt Crees authored
We don't use dots in the image name Change-Id: I29172448c14a1ca9a5fa23abe701366f875959e0
-
- Sep 11, 2024
-
-
Matt Crees authored
This isn't obvious from reading of the docs, let's make sure users are aware. Change-Id: I0da1ad16bfab00bed7e935cca118551a6c5860c6
-
- Aug 29, 2024
-
-
Matt Crees authored
Given we bump the RabbitMQ version each release, there is a manual upgrade to an intermediary RabbitMQ version needed before a skip-level upgrade can be performed. Change-Id: Id8a5ebe19a50ebdc59d12667889472c803b8d7c8
-
- Aug 12, 2024
-
-
Matt Crees authored
Required before a SLURP upgrade Change-Id: I09a45d26a6075554b204e007f64122f23de5f53c
-
- Dec 06, 2023
-
-
Matt Crees authored
RabbitMQ does not need to be reconfigured when migrating from non-HA queues to quorum queues. Change-Id: I69d409732ff8eb7ae736e95f8a5d290efd33fa32
-
- Nov 30, 2023
-
-
Sven Kieske authored
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
-
- Aug 25, 2023
-
-
Matt Crees authored
This command can be invoked with ``kolla-ansible rabbitmq-reset-state``. This is primarily designed to be used when enabling HA queues[1]. As such, this also updates the RabbitMQ documentation to use this command. [1] https://docs.openstack.org/kolla-ansible/latest/reference/message-queues/rabbitmq.html#high-availability Change-Id: I6ad95a3618fc1a34af56657ef99ef14dc979f17a
-
- Apr 19, 2023
-
-
Matt Crees authored
Currently, the process of enabling RabbitMQ HA with the variable ``om_enable_rabbitmq_high_availbility`` requires some manual steps to migrate from transient to mirrored queues. In preparation for setting this variable to ``True`` by default, this adds a precheck that will fail if a system is currently running non-mirrored queues and ``om_enable_rabbitmq_high_availbility`` is set to ``True``. Includes a helpful message informing the operator of their choice. Either follow the manual procedure to migrate the queues described in the docs, or set ``om_enable_rabbitmq_high_availbility`` to ``False``. The RabbitMQ HA section of the reference docs is updated to include these instructions. Change-Id: Ic5e64998bd01923162204f7bb289cc110187feec
-
- Jan 13, 2023
-
-
Matt Crees authored
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
-
- Jul 28, 2021
-
-
Radosław Piliszek authored
As mentioned in the Iced014acee7e590c10848e73feca166f48b622dc commit message, in Ussuri+ we can use ``+sbwtdcpu none +sbwtdio none`` as well. This is due to relying on RMQ-provided erlang in version 23.x. This change adds the extra arguments by default. It should be backported down to Ussuri before we do a release with Iced014acee7e590c10848e73feca166f48b622dc. Change-Id: I32e247a6cb34d7f6763b544f247fd408dce2b3a2
-
- Jul 27, 2021
-
-
wu.chunyang authored
Nova always tries to create the rabbitmq user regardless of whether RabbitMQ is enabled or not. This ps also adds an external rabbitmq doc. Change-Id: Iec517226e4c82ea351889b55689a3efceaadcc76
-
- Jun 07, 2021
-
-
John Garbutt authored
On machines with many cores, we were seeing excessive CPU load on systems that were not very busy. With the following Erlang VM argument we saw RabbitMQ CPU usage drop from about 150% to around 20%, on a system with 40 hyperthreads. +S 2:2 By default RabbitMQ starts N schedulers where N is the number of CPU cores, including hyper-threaded cores. This is fine when you assume all your CPUs are dedicated to RabbitMQ. Its not a good idea in a typical Kolla Ansible setup. Here we go for two scheduler threads. More details can be found here: https://www.rabbitmq.com/runtime.html#scheduling and here: https://erlang.org/doc/man/erl.html#emulator-flags +sbwt none This stops busy waiting of the scheduler, for more details see: https://www.rabbitmq.com/runtime.html#busy-waiting Newer versions of rabbit may need additional flags: "+sbwt none +sbwtdcpu none +sbwtdio none" But this patch should be back portable to older versions of RabbitMQ used in Train and Stein. Note that information on this tuning was found by looking at data from: rabbitmq-diagnostics runtime_thread_stats More details on that can be found here: https://www.rabbitmq.com/runtime.html#thread-stats Related-Bug: #1846467 Change-Id: Iced014acee7e590c10848e73feca166f48b622dc
-
- Sep 17, 2020
-
-
Mark Goddard authored
This change adds support for encryption of communication between OpenStack services and RabbitMQ. Server certificates are supported, but currently client certificates are not. The kolla-ansible certificates command has been updated to support generating certificates for RabbitMQ for development and testing. RabbitMQ TLS is enabled in the all-in-one source CI jobs, or when The Zuul 'tls_enabled' variable is true. Change-Id: I4f1d04150fb2b5af085b762890092f87ae6076b5 Implements: blueprint message-queue-ssl-support
-
- Oct 25, 2019
-
-
Jan Vondra authored
Adds rabbitmq_server_additional_erl_args variable which is appended to RABBITMQ_SERVER_ADDITIONAL_ERL_ARGS environment variable to RabbitMQ server startup script. This can be used to configure the schedulers. Docs attached. Change-Id: Id683c8cc6dac61354ffd94f3b460335b42136ba2 Co-authored-by:
Radosław Piliszek <radoslaw.piliszek@gmail.com> Related-bug: #1846467
-