Open Stack

On Sat, 22 Jul 2023 at 13:12, Thomas Goirand <zigo at debian.org> wrote:
>
> On 7/21/23 16:16, smooney at redhat.com wrote:
> > we have consider that in the past and the reality is it would be a massive rewrite
> > we considerd doing this when we were dicussiong moving to python3 and at various points since
> > the problem is two fold. 1 we dont have contibutors able to work on this currently. 2 we dont have
> > a good solution for how to do this incrementally.
> >
> > in nova at least we did breicly consider tyring to add asyncio console-script entries points
> > so that we couuld have an eventlet version and non eventlet version of each service to act as a bridge
> > its somethign we could discuss again but makign such a change without introducing bugs or performance regressions
> > would require a lot of careful engenieing work.
> >
> > i would love to regarin the ablity ot run nova under a debugger and drop the dep on eventlet but i dont want
> > to do that at the expense of stablity or perfromace for our customer.
> >
> > some services liek the api and schduler would be relitivly simple to port. the compute agent and conductor on the other
> > hand rely on the implict acync behavior to fucntion at all. nova-comptue with libvirt as at lest 3 while true loops
> > to compunticate with rabbit, libvirt and privsep to name just one of the the issues tha towuld need to be resolved.
>
> THere's probably another route. What if we were to somehow fork
> Eventlet, make it stop doing monkey patching, and reimplement its calls
> using asyncio? Do you think such approach would work? If so, it would
> have the huge advantage to implement the changes for all projects at
> once. Your thoughts?

zigo, the problem is that nova et al are relying on this monkey
patching to work.
So we are back to "rewrite it all so that it works in asyncio".