Open Stack

Thanks, Sean. Your summary is more elaborate. And I meant asyncio*, not
async programming. Sorry for any confusion.



On Fri, 21 Jul 2023, 13:32 , <smooney at redhat.com> wrote:

> 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
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.openstack.org/pipermail/openstack-discuss/attachments/20230721/bcbc7463/attachment-0001.htm>