2024.1 Series Release Notes

14.7.1

Bug Fixes

  • Force queue deletion when it is not possible de redeclare a queue. See bug 2068630 for details.

14.7.0

New Features

  • Add three new options (use_queue_manager, hostname, processname) to switch oslo.messaging from random queue names (for reply_q and fanouts) to consistent naming. The default value is False, so oslo.messaging will still use random queue names if nothing is set in configuration file of services. When switching use_queue_manager to True, the uuid4 random string from the queue name is replaced with a combination of hostname, processname and counter. The counter will be kept in shared memory (/dev/shm/x_y_qmanager). This way, when a service using oslo.messaging restarts (e.g. neutron), it will re-create the queues using the same name as the previous run, so no new queues are created and no need for rabbitmq to delete the previous queues. This is extremely useful for operator to debug which queue belong to which server/process. It’s also higlhy recommended to enable this feature when using quorum queues for transient (option named rabbit_transient_quorum_queue) to avoid consuming all erlang atoms after some time.

  • Add an option to enable transient queues to use quorum.

    Transient queues in OpenStack are not so transient, they live the whole process lifetime (e.g. until you restart a service, like nova-compute). Transient here means they belong to a specific process, compared to regular queues which may be used by more processes. Usually, transients queues are the “fanout” and “reply” queues.

    By default, without any rabbitmq policy tuning, they are not durable neither highly available.

    By enabling quorum for transients, oslo.messaging will declare quorum queues instead of classic on rabbitmq. As a result, those queues will automatically become HA and durable. Note that this may have an impact on your cluster, as rabbit will need more cpu, ram and network bandwith to manage the queues. This was tested at pretty large scale (2k hypervisors) with a cluster of 5 nodes.

    Also note that the current rabbitmq implementation rely on a fixed number of “erlang atom” (5M by default), and one atom is consumed each time a quorum queue is created with a different name. If your deployment is doing a lot of queue deletion/creation, you may consume all your atoms quicker.

    When enabling quorum for transients, you may also want to update your rabbitmq policies accordingly (e.g. make sure they apply on quorum).

    This option will stay disabled by default for now but may become the default in the future.

  • The name of the reply_q is now logged when a timeout occurs while waiting for a reply.

  • Add an option to use stream queues for rabbitmq driver instead of fanouts.

14.6.0

New Features

  • Allow creation of transient queues with no expire. When an operator rely on rabbitmq policies, there is no point to set the queue TTL in config. When the rabbit_transient_queues_ttl is set to 0, no x-expire parameter will be set on queue declaration. In that specific situation, it is recommended to set an expire value using rabbitmq policies. See https://www.rabbitmq.com/parameters.html#policies

Bug Fixes

  • Auto-delete the failed quorum rabbit queues. When rabbit is failing for a specific quorum queue, delete the queue before trying to recreate it. This may happen if the queue is not recoverable on rabbit side. See https://www.rabbitmq.com/quorum-queues.html#availability for more info on this specific case.

14.5.0

Bug Fixes

  • Change heartbeat_rate default from 2 to 3 in order to send AMQP heartbeat frames at correct interval