[neutron] oslo.messaging and port notifications broadcast
Hi, 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? Cheers, Thomas Goirand (zigo)
Hi, I would say that this is due to the fact that the notifications are sent to topic queues. When using rabbitmq, these queues would be classic or quorum and that mean the unicity of messages (at least by default, I don't know if there is a way to duplicate messages like this in rabbti). What you need is the notifications to be sent to fanout queues (or streams), so multiple consumers could have the same messages. I don't believe this is doable from current oslo.messaging implementation, but that does not sounds a huge change to perform for a POC. Regards, Arnaud On 18.09.25 - 23:12, Thomas Goirand wrote:
Hi,
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?
Cheers,
Thomas Goirand (zigo)
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. --Dan
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/e95f334459d4dfd3778ec9e84... 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/4b1941221f1f51a0432cb96bc0b... https://github.com/openstack/oslo.messaging/blob/4b1941221f1f51a0432cb96bc0b... the rabbit implementation is here https://github.com/openstack/oslo.messaging/blob/4b1941221f1f51a0432cb96bc0b... 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/4b1941221f1f51a0432cb96bc0b... regards sean.
--Dan
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. Cheers, Thomas Goirand (zigo)
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)
On 9/30/25 2:56 PM, Sean Mooney wrote:
i asked this qustion on irc but how exactly are you sendign the notificaiton
I'm not. Neutron is... I want port notifications for create / update / delete.
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/ notify/notifier.py#L210-L221
I'm just setting fanout true/false on the receiver side, as I'm not doing the notifier.info() thing myself, Neutron is... Cheers, Thomas Goirand (zigo)
When I set pool=<hostname>, with fanout=True OR fanout=False, no mater what, none of my daemons are receiving Neutron port notifications.
FWIW, I never got it to work either. In trying to track down why, I started to realize that it was sort of client-based re-queuing the message and thus lost interest in it as a solution. Hence my "if it works for you" hedging in my initial reply. I do think Gibi got it to work at one point though, maybe he can offer some clues.
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 think the ability to fanout notifications _is_ a missing feature, yes. I think the pooling is the current implementation for oslo.messaging to achieve the desired behavior (even if not via the mechanism I would choose). So aside from a bug (if it's broken, which it seemed to me that it was) I don't know that there's any doc changes required as the current stuff explains that one receiver will get the notification (pool mode excepted). --Dan
On Tue, Sep 30, 2025 at 4:55 PM Dan Smith <dms@danplanet.com> wrote:
When I set pool=<hostname>, with fanout=True OR fanout=False, no mater what, none of my daemons are receiving Neutron port notifications.
FWIW, I never got it to work either. In trying to track down why, I started to realize that it was sort of client-based re-queuing the message and thus lost interest in it as a solution. Hence my "if it works for you" hedging in my initial reply.
I do think Gibi got it to work at one point though, maybe he can offer some clues.
Yeah I saw it working but it was a while ago. Digging my notes I found https://gist.github.com/gibizer/f629ba50290fe081f358079da8628e38 You need a pool key defined and also you need to explicitly declare an exchange then it worked for me. Cheers, gibi
Yeah I saw it working but it was a while ago. Digging my notes I found https://gist.github.com/gibizer/f629ba50290fe081f358079da8628e38
You need a pool key defined and also you need to explicitly declare an exchange then it worked for me.
Oh yes, I remember the exchange thing now. I think I did eventually get it working after you pointed that out, but I had already decided against it for other reasons. Gibi++ for taking good notes :) --Dan
On 9/30/25 5:02 PM, Balazs Gibizer wrote:
On Tue, Sep 30, 2025 at 4:55 PM Dan Smith <dms@danplanet.com> wrote:
When I set pool=<hostname>, with fanout=True OR fanout=False, no mater what, none of my daemons are receiving Neutron port notifications.
FWIW, I never got it to work either. In trying to track down why, I started to realize that it was sort of client-based re-queuing the message and thus lost interest in it as a solution. Hence my "if it works for you" hedging in my initial reply.
I do think Gibi got it to work at one point though, maybe he can offer some clues.
Yeah I saw it working but it was a while ago. Digging my notes I found https://gist.github.com/gibizer/f629ba50290fe081f358079da8628e38
You need a pool key defined and also you need to explicitly declare an exchange then it worked for me.
Cheers, gibi
Thanks. I did both a pool and an exchange. The only thing I see differs from what I have is the allow_requeue=False. Is this mandatory too? Cheers, Thomas Goirand (zigo)
On Wed, Oct 1, 2025 at 12:03 PM Thomas Goirand <zigo@debian.org> wrote:
On 9/30/25 5:02 PM, Balazs Gibizer wrote:
On Tue, Sep 30, 2025 at 4:55 PM Dan Smith <dms@danplanet.com> wrote:
When I set pool=<hostname>, with fanout=True OR fanout=False, no mater what, none of my daemons are receiving Neutron port notifications.
FWIW, I never got it to work either. In trying to track down why, I started to realize that it was sort of client-based re-queuing the message and thus lost interest in it as a solution. Hence my "if it works for you" hedging in my initial reply.
I do think Gibi got it to work at one point though, maybe he can offer some clues.
Yeah I saw it working but it was a while ago. Digging my notes I found https://gist.github.com/gibizer/f629ba50290fe081f358079da8628e38
You need a pool key defined and also you need to explicitly declare an exchange then it worked for me.
Cheers, gibi
Thanks.
I did both a pool and an exchange. The only thing I see differs from what I have is the allow_requeue=False. Is this mandatory too?
Unfortunately I don't remember, my guess is that it is not mandatory.
Cheers,
Thomas Goirand (zigo)
maybe something like this may help you https://review.opendev.org/c/openstack/oslo.messaging/+/963475 cheers On 30.09.25 - 13: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.
Cheers,
Thomas Goirand (zigo)
participants (5)
-
Arnaud Morin
-
Balazs Gibizer
-
Dan Smith
-
Sean Mooney
-
Thomas Goirand