[all] [oslo.messaging] Interest in collaboration on a NATS driver

Christian Rohmann christian.rohmann at inovex.de
Thu Jul 20 10:11:51 UTC 2023


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




More information about the openstack-discuss mailing list