On 30/06/2023 11:45, Dmitriy Rabotyagov wrote:
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.
In case all of the queue type specifics only live in oslo.messaging and are abstracted away from the application I believe you are totally right. I was simply looking at [1] in which certain features, if used, might require changes within the application. This led me to believe this required a broader effort across the projects to make this change. But in the end the recommendation of a migration to quorum queues, however done technically, to me should rather be a goal and general release note for an OpenStack release. With the deprecation of classic mirrored queues within RabbitMQ this migration needs to happen sooner or later anyways. To me it makes no sense to change for one component, but not for another. Choice in migration speed and config options are always nice (like [3]), but in the end it's a required cut over from one type to another with no need to keep support for classic queues after a "bridge release" or two supporting both.
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.
Do you have a pointer to those efforts for me to follow? A Gerrit topic or bug? [1] https://www.rabbitmq.com/migrate-mcq-to-qq.html#mcq-changes-way-queue-is-use... which [2] https://review.opendev.org/c/openstack/oslo.messaging/+/888479 [3] https://review.opendev.org/c/openstack/oslo.messaging/+/888479 Regards Christian