On 30/09/2025 12:20, Thomas Goirand wrote:
On 9/29/25 1:39 PM, Sean Mooney wrote:
On 22/09/2025 16:04, Dan Smith wrote:
Is it possible, with oslo.messaging, to have 3 daemons to get the Neutron port.{create,update,delete}.end notification events?
I tried hard, but no mater how I do it, only one of my 3 daemons get the message. I'm about to add forwarding feature to the other 2 when one receives an event. Is there a better way? I think you're looking for the "pool" parameter:
https://docs.openstack.org/oslo.messaging/ocata/ notification_listener.html
That is supposed to make it so that all the receivers in the same pool get a copy. I'm not sure, but I think this is implemented in some re- queuing way that is likely not very robust. But, if it works for you it might be good enough.
I agree it would be much better for the notification stuff to be (or at least have the option to be) sent in a fanout manner.
im not very familar with it but newer veriosn of rabbit have the consept of a stream instead of a queue looking at the use cases https://www.rabbitmq.com/docs/streams#use-cases i belive that long term that would be the rabbit native way to support notification in a more robust multi consumer fashion
recent versions of oslo messaging (caracal+) now support using streams instead of fanouts
https://github.com/openstack/oslo.messaging/commit/ e95f334459d4dfd3778ec9e84d716f69f2c08ad5
Julien Cosmao is giving a talk called "who framed rabbitMQ?" that cover the performance improvements in rabbit and oslo messaging that is schduled for the paris sumit in a few week that i belive is goign to cover some of the more recent features.
https://summit2025.openinfra.org/a/schedule# "Who framed RabbitMQ?: Sat, October 18, 5:05pm - 5:35pm | Pierre Faurre"
but i agree that using a fan-out ideally via stream would likely be the best way to achieve that
i think dan is corerc that using a fanout is not how the pools parameter works today im not sure if the pool parmater can be used in combination with rabbit_stream_fanout=true to achive that in the future
but perhaps that could be a future enhancement to oslo.messaging if not.
if the entiry notifaction topic was a stream and the pool parmater was mapped to a partition of that stream, aka Superstreams (Partitioned Streams)
https://www.rabbitmq.com/docs/streams#super-streams
or using filterign https://www.rabbitmq.com/docs/streams#filtering on the pool.
as i said i am not famialr enough with these newer features to say either way but there is at least a direction to eveolved this in the future
looping back to dans suggestion the pool parmater dan is refering too is documented here
https://github.com/openstack/oslo.messaging/ blob/4b1941221f1f51a0432cb96bc0b2e8203ac2fcb8/oslo_messaging/_drivers/ base.py#L460-L464 https://github.com/openstack/oslo.messaging/ blob/4b1941221f1f51a0432cb96bc0b2e8203ac2fcb8/oslo_messaging/_drivers/ base.py#L553-L560
the rabbit implementation is here
https://github.com/openstack/oslo.messaging/ blob/4b1941221f1f51a0432cb96bc0b2e8203ac2fcb8/oslo_messaging/_drivers/ amqpdriver.py#L825-L836
the driver use callback to process the incomming mseages wso its a littel hard to follow but i bleive this is the one that is invoked
"""
The *pool* parameter, if specified, should cause the driver to create a subscription that is shared with other subscribers using the same pool identifier. Each pool gets a single copy of the message. For example if there is a subscriber pool with identifier **foo** and another pool **bar**, then one **foo** subscriber and one **bar** subscriber will each receive a copy of the message. The driver should implement a delivery pattern that distributes message in a balanced fashion across the subscribers in a pool."""
if we read the description of the pool parmater if you want all 3 deamson to get the message alwasy then you should set pool to a unique value per deamon i.e. its uuid or hostname if you want ot guarentee that exactly 1 of them will always get it then it should be set to the same value if you wnat ot leave it up to the admin to choose the behavior then i would make it a config option.
i cant follow the oslo logic closely enough to say if the rabbit logic is internally requing or if its smarter but here definly is reque logic in NotificationAMQPIncomingMessage
https://github.com/openstack/oslo.messaging/ blob/4b1941221f1f51a0432cb96bc0b2e8203ac2fcb8/oslo_messaging/_drivers/ amqpdriver.py#L312-L324
regards
sean.
--Dan
Thank all of you (Arnaud, Dan and Sean) for your answers.
However, I can't get something to do what I want.
When I set fanout=True, and pool not set, only a single daemon receives the notifications. This by the way proves that I'm listening on the correct topic and exchange.
When I set pool=<hostname>, with fanout=True OR fanout=False, no mater what, none of my daemons are receiving Neutron port notifications.
So oslo_messaging isn't doing what it pretend it should? Or I am missing something, like another parameter is wrong? Is this really a miss-feature of oslo_messaging? If so, then the doc should be fixed.
i asked this qustion on irc but how exactly are you sendign the notificaiton you are ment to do that by constucting a notifyer object and then calliing .info or .error ectra method on the notify which will internally constuct the target object that carry the fanout option you shoudl not be using any of the internal transport or driver method directly the reaons i ask is the public interface fo the notifyer object does tno allow you to set fanout one way or another and it will not set it itself. so the fact your asking this quest impleise that you are not actully using the public interface for sending notifications. https://github.com/openstack/oslo.messaging/blob/master/oslo_messaging/notif...
Cheers,
Thomas Goirand (zigo)