On 8/29/22 13:20, Radosław Piliszek wrote:
On Mon, 29 Aug 2022 at 20:03, Sean Mooney <smooney@redhat.com> wrote:
Finally, have you considered just trying out ZeroMQ? ZeroMQ used to be supported in the past but then it was remvoed if i understand correctly it only supprot notificaiton or RPC but not both i dont recall which but perhapse im miss rememebrign on that point.
I believe it would be better suited for RPC than notifications, at least in the simplest form.
I believe it was the opposite. ZeroMQ could handle fire-and-forget notifications fine, but when you started trying to coordinate with the receivers the way oslo.messaging does it was missing features that had to be implemented in the o.m driver. Once you added everything needed for a fully functional OpenStack messaging driver you ended up negating a lot of the benefits of ZeroMQ. It just wasn't a good fit for the messaging model we use. Caveat: I am not a messaging expert so I'm just regurgitating the things I've heard from the messaging experts I've discussed this with.
I mean, NATS is probably an overkill for OpenStack services since the majority of them stay static on the hosts they control (think nova-compute, neutron agents - and these are also the pain points that operators want to ease). its not any more overkill then rabbitmq is
True that. Probably.
i also dont know waht you mean when you say "majority of them stay static on the hosts they control"
NATS is intended a s a cloud native horrizontally scaleable message bus. which is exactly what openstack need IMO.
NATS seems to be tweaked for "come and go" situations which is an exception in the OpenStack world, not the rule (at least in my view). I mean, one normally expects to have a preset number of hypervisors and not them coming and going (which, I agree, is a nice vision, could be a proper NATS driver, with more awareness in the client projects I believe, would be an enabler for more dynamic clouds).
Cheers, Radek -yoctozepto