Hey Tobias,
On 15/07/2023 16:27, Tobias Urdin wrote:
The effort is mostly now to get/find a supported third-party Python library that does not use asyncio for usage in a oslo.messaging driver.
The investigation into introducing asyncio support in the ecosystem (oslo and then all separate projects) was a too massive effort.
Since then I’ve opened an issue [1] on the nats.py GitHub and some proof-of-concept patches [2] on introducing synchronous support in nats.py that we could then use in a driver.
The oslo.messaging driver patch [3] has Devstack passing when using [2] but it’s also more of a proof-of-concept patch that would need more work in itself.
Unfortunately I didn’t get any feedback from the company maintaining the nats.py library on supported developer time implemeting the sync client feature, I assume (my view) that they didn’t like that we cannot guarantee that NATS would become a core component (or used, or the primary bus) in the ecosystem (since we don’t, and don’t want to for that matter, force a backend/driver on operators).
Any help is of course appreciated, right now this is not a top priority and I don’t spend any full-time effort into it.
Best regards Tobias
[1] https://github.com/nats-io/nats.py/issues/462 [2] https://github.com/tobias-urdin/nats.py/commits/sync-client [3] https://review.opendev.org/c/openstack/oslo.messaging/+/878588
Thanks for the rapid response and full overview of your NATS endeavors! I shall subscribe to your kindly linked issues. There currently also is a larger number of fixes for oslo.messaging via RabbitMQ incoming: a shift to quorum queues, fixed threading for heartbeats, adjusted timers and timeouts, .... Maybe they relieve a bit of the perceived pain with (oslo.messaging via) RabbitMQ.
To me it's not about having even more choices in messaging drivers (or coordination backends for that matter). All of them working slightly different, having different features and them each having +50 options to fiddle with all sorts of timers or adjust other settings. I'd rather have a single solution that is broadly used by most installs and that, proper setup, configuration and scaling provided, "just works". Even though there is an abstraction with oslo.(messaging|coordination), there always remain implications for the OpenStack components depending on which backend / driver one uses.
Anyways, thanks again for your response! Regards
Christian