Open Stack

Hey,

1. I'm not sure if that's a proper community goal, simply because it
boils down to individual deployments and affects a really minority of
projects, like oslo.messaging and deployment projects. Moreover, this
affects only rabbit driver, which is the most popular option in
oslo.messaging but not the only one. Usually community goal is used
when you need to apply changes to the absolute majority of services,
like in case with SQLAlchemy. So here I think we should discuss more
default behaviour of oslo.messaging for rabbit driver and default
value of rabbit_quorum_queue, which is basically up to oslo team to
decide.
2. In OpenStack-Ansible we already agreed on the latest PTG to make
Quorum queues a new default and introduce migration to them. So it
should be inlcuded in 2023.2 (bobcat) release, with keeping the
upgrade path at very least to 2024.1 which will be the next SLURP.

пт, 30 июн. 2023 г. в 11:05, Christian Rohmann <christian.rohmann at inovex.de>:
>
> On 18/06/2023 04:04, Satish Patel wrote:
> > Great! This is good to know that Quorum is a good solution.
>
> Everybody in this thread seems to have good experiences with using
> quorum queues and also RabbitMQ themselves clearly communicate that
> Quorum Queues are the future and classic queues will be gone soon:
>
>   * "Classic mirrored queues were deprecated in RabbitMQ version 3.9" -
> https://www.rabbitmq.com/migrate-mcq-to-qq.html
>   *
> https://blog.rabbitmq.com/posts/2021/08/4.0-deprecation-announcements/#removal-of-classic-queue-mirroring
>
> I wonder why there is not more effort to make this shift by  ...
>
>
> a) Why this is not an OpenStack tc goal for all services to use quorum
> queues by default initialize any new queues as quorum queues?
> Especially since "An oslo.messaging-compatible message queue" is one of
> the base services [2] overseen by the TC.
> RabbitMQ comes up time and again when talking about operational issues
> when running OpenStack. Steps to ensure this vital piece runs as smooth
> as possible is certainly worth discussing in my humble opinion.
>
> I don't know if anyone on the TC reads this, but does it make sense to
> propose such a goal to https://opendev.org/openstack/governance ?
>
> b) Have deployment tooling like openstack-ansible, kolla-ansible, ...
> support setting the oslo.messaging options [1] or even make quorum
> queues the new default
>
>
> Regards
>
>
> Christian
>
>
>
>
> [1]
> https://docs.openstack.org/releasenotes/oslo.messaging/yoga.html#relnotes-12-13-0-stable-yoga
> [2]
> https://governance.openstack.org/tc/reference/base-services.html#current-list-of-base-services
>
>
>
>
>
>