62fb57b2d7
HA policies were replaced with quorum queues [1] and discuouraged and marked for removal in 4.0 [2] Based on that we perform migration from HA queues to quorum, since they're already supported in oslo.messaging. Patches per-service are required to enable quorum queues in service configuration. This also adjusts upgrade doc to contain a variable required for proper nova cell update on changed vhost. [1] https://www.rabbitmq.com/quorum-queues.html [2] https://blog.rabbitmq.com/posts/2021/08/4.0-deprecation-announcements/ Change-Id: Icd5eabcad4801b454f29b388613d7241bb9b0ad0
26 lines
1.0 KiB
YAML
26 lines
1.0 KiB
YAML
---
|
|
upgrade:
|
|
- |
|
|
During upgrade HA policy for RabbitMQ will be disabled and replaced with
|
|
usage of quorum queues which is a new and more efficient way to ensure
|
|
queues durability.
|
|
|
|
If you want to continue using HA queues instead of quorum queues, please
|
|
specify in your user_variables.yml:
|
|
|
|
.. code-block:: yaml
|
|
|
|
oslomsg_rabbit_quorum_queues: False
|
|
|
|
If ``oslomsg_rabbit_quorum_queues`` is enabled (default behaviour),
|
|
RabbitMQ vhosts will be re-created without leading ``/``. Ensure to
|
|
reflect these changes in your monitoring software if vhosts are not
|
|
auto-discovered.
|
|
Also changing vhost name will result in prolonged downtime for services,
|
|
as not re-configured yet backends will fail to connect to RabbitMQ until
|
|
restart.
|
|
It also might be worth to process upgrade with extra caution for some
|
|
serivices that are sensetive to RabbitMQ downtime or even disabling usage
|
|
of quorum queues for these services. Good examples of such services
|
|
are Trove or Neutron with ML2 LXB or ML2 OVS drivers.
|