[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