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

Radosław Piliszek radoslaw.piliszek at gmail.com
Fri Jul 21 09:59:00 UTC 2023


On Fri, 21 Jul 2023 at 09:03, Thomas Goirand <zigo at debian.org> wrote:
>
> On 7/15/23 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.
>
> Sorry to ask, but what's the problem with asyncio? Do we want something
> *not* async? If yes, why?

Large swaths of OpenStack code are not ready for async.
We want to take baby steps and get to some better place with tangible benefits.

> > 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.
>
> Would it help if I was packaging NATS in Debian (and therefore, as a
> consequence, in Ubuntu)? By reading the go.mod, it feels like it has a
> reasonable amount of dependencies (though I didn't check for the
> indirect ones), so it feels like doable...

NATS's preferred way of delivery is a single (!) binary offered by the upstream.
I guess you could help considerably with minimum effort by repackaging
it into a deb so that users going for apt hunting get the upstream
NATS.
Then it would only boil down to finally packaging the Python library
that works well with both OpenStack and NATS but we don't have it yet.

Kind regards,
Radek
-yoctozepto



More information about the openstack-discuss mailing list