Tuesday, 2024-05-21

damani2hi08:18
damani2tkajinam, can you check please https://review.opendev.org/c/openstack/oslo.log/+/91842608:20
damani2i think that can be merge 08:20
kevkoHi folks 11:00
kevkoi would like to ask how to migrate classic queues to quorum queus on the fly 11:01
kevkowe have 160 +/- hypervisors ...11:01
kevkoi really don't want to imagine what all will be broken and how big affect it will be to restart all services to create new quorum-queus queue types11:02
kevkoi wondered if oslo.messaing don't have support to just turn on both during the migration and after migration just switch off that mode ....11:03
kevkoor how can I handle this ? 11:03
kevkowe have 1000+ k8s clusters which are very sensitive for volume attachments for example ..and starts reclustering ...it's production :( 11:03
kevkoanybody here ? 14:09
jrosser_kevko: there is probably more interest in that from whatever deployment tooling you use than the oslo team14:26
hberaudkevko: I'd argue that's it dependens on the way you use the oslo.messaging API. The quorum flag is a global flag which rely on the queue-type argument given at queue creation (https://www.rabbitmq.com/docs/quorum-queues#declaring), the connection object is not really configurable and will apply the default config15:07
hberaudhttps://opendev.org/openstack/oslo.messaging/src/branch/master/oslo_messaging/_drivers/impl_rabbit.py#L701 but the consumer object is configurable about the queue type...15:07
hberaudso in other words, if you use the high level API of the rabbitmq driver of oslo.messaging, then IMO that's all or nothing, I don't seen way to using both during migration and then just switch off that mode15:08
hberaudbut if you manually use some "low" level API aspects of the same driver, like, consumer, then I think it would be possible to implement some sort of switchable migration scenario, but that would be handcrafted15:11

Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!