Comment 5 for bug 1854992

Revision history for this message
melanie witt (melwitt) wrote :

This came up again today in #openstack-nova [1] where sean-k-mooney and I were discussing how we could leverage the new(-ish) 'mandatory' oslo.messaging option [2] in nova to recover from a rabbitmq queue being gone.

What (we think) we understand so far is that we could specify the mandatory=True flag to the RPCClient at construction time, that would cause it to raise MessageUndeliverable if the rabbit queue has gone away, and then we'd have to try-except to handle MessageUndeliverable and create the queue in that case.

What we don't know yet is if we could put that try-except in a tidy, central place in nova/rpc.py and thus have any component who hits MessageUndeliverable create the queue -- that is, if nova-conductor gets MessageUndeliverable, can it create the queue and if it does, will nova-compute listen be able to listen on it without having to re-init? Or will nova-compute need to re-init?

Sean might be able to experiment a bit with a setup to test some ideas out and determine what's the best way we can handle queue re-creates + listening.

[1] http://eavesdrop.openstack.org/irclogs/%23openstack-nova/%23openstack-nova.2020-06-04.log.html#t2020-06-04T17:27:23
[2] https://github.com/Gsantomaggio/rabbitmq-utils/tree/master/openstack/mandatory_test