<div dir="auto">Thanks, Sean. Your summary is more elaborate. And I meant asyncio*, not async programming. Sorry for any confusion.<div dir="auto"><br></div><div dir="auto"><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, 21 Jul 2023, 13:32 , <<a href="mailto:smooney@redhat.com">smooney@redhat.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Fri, 2023-07-21 at 11:59 +0200, Radosław Piliszek wrote:<br>
> On Fri, 21 Jul 2023 at 09:03, Thomas Goirand <<a href="mailto:zigo@debian.org" target="_blank" rel="noreferrer">zigo@debian.org</a>> wrote:<br>
> > <br>
> > On 7/15/23 16:27, Tobias Urdin wrote:<br>
> > > The effort is mostly now to get/find a supported third-party Python library that does not<br>
> > > use asyncio for usage in a oslo.messaging driver.<br>
> > <br>
> > Sorry to ask, but what's the problem with asyncio? Do we want something<br>
> > *not* async? If yes, why?<br>
> <br>
> Large swaths of OpenStack code are not ready for async.<br>
> We want to take baby steps and get to some better place with tangible benefits.<br>
that not entirly correct.<br>
much of openstack is already async but we made a decision ot use eventlet as our async model many many<br>
years ago after we ported form twisted.<br>
<br>
The problem is you cannot really mix eventlet code and asyncio safely in the python process.<br>
That means you cannot have the async nats lib used in nova,swift,cinder,neutron, glance and progrably other<br>
projects today.<br>
<br>
i proposed one option a long time ago which is to take a privsep like approch where we spawn the oslo messaging driver<br>
into a sperate process and comunicate with it over a unix socket.<br>
<br>
that would allow the oslo.messaging drvier to run with asynio and all the existing project to consume it unmodifed.<br>
a unix socket is just one way to hanel that of couse you coudl use any other ipc liek shared memory but the<br>
core logic for that exist in oslo.privsep in the form of the chanels it provids so we have prior art to work form.<br>
<br>
but thats the main problem. most of openstack uses eventlets for implict async.<br>
eventlets and explict async are not safe to mix in the same process.<br>
and that is the bocker to the current python nats driver as far as i am aware.<br>
> <br>
> > > Unfortunately I didn’t get any feedback from the company maintaining the nats.py library<br>
> > > on supported developer time implemeting the sync client feature, I assume (my view) that<br>
> > > they didn’t like that we cannot guarantee that NATS would become a core component (or used, or the primary bus)<br>
> > > in the ecosystem (since we don’t, and don’t want to for that matter, force a backend/driver on operators).<br>
> > > <br>
> > > Any help is of course appreciated, right now this is not a top priority and I don’t spend any full-time<br>
> > > effort into it.<br>
> > <br>
> > Would it help if I was packaging NATS in Debian (and therefore, as a<br>
> > consequence, in Ubuntu)? By reading the go.mod, it feels like it has a<br>
> > reasonable amount of dependencies (though I didn't check for the<br>
> > indirect ones), so it feels like doable...<br>
> <br>
> NATS's preferred way of delivery is a single (!) binary offered by the upstream.<br>
> I guess you could help considerably with minimum effort by repackaging<br>
> it into a deb so that users going for apt hunting get the upstream<br>
> NATS.<br>
> Then it would only boil down to finally packaging the Python library<br>
> that works well with both OpenStack and NATS but we don't have it yet.<br>
> <br>
> Kind regards,<br>
> Radek<br>
> -yoctozepto<br>
> <br>
<br>
</blockquote></div>