Open Stack

On Fri, 2023-07-21 at 11:59 +0200, Radosław Piliszek wrote:
> 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.
that not entirly correct.
much of openstack is already async but we made a decision ot use eventlet as our async model many many
years ago after we ported form twisted.

The problem is you cannot really mix eventlet code and asyncio safely in the python process.
That means you cannot have the async nats lib used in nova,swift,cinder,neutron, glance and progrably other
projects today.

i proposed one option a long time ago which is to take a privsep like approch where we spawn the oslo messaging driver
into a sperate process and comunicate with it over a unix socket.

that would allow the oslo.messaging drvier to run with asynio and all the existing project to consume it unmodifed.
a unix socket is just one way to hanel that of couse you coudl use any other ipc liek shared memory but the
core logic for that exist in oslo.privsep in the form of the chanels it provids so we have prior art to work form.

but thats the main problem. most of openstack uses eventlets for implict async.
eventlets and explict async are not safe to mix in the same process.
and that is the bocker to the current python nats driver as far as i am aware.
> 
> > > 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
>