On Wed, 2024-10-09 at 12:01 +0200, Sylvain Bauza wrote:
> Le ven. 4 oct. 2024 à 17:41, engineer2024 <engineerlinux2024@gmail.com> a
> écrit :
>
> > That's encouraging news. I hope the new alternative would support a python
> > debugger like pdb. This will help the new users to understand the
> > flow better. So when can we expect initial release atleast beta of eventlet
> > free nova components ?
> >
> >
> That's an excellent question that I don't have an answer. We started to
> work on it on Dalmatian but for the moment, I don't know whether the owner
> could continue to work on it on Epoxy or if someone else would do it.
i dont think we will ever have a "beta" release without eventlet
our expection is that we will do a phased removal.

so the iniall goal was to to tackel some of the low hanging furit in dalmation
the first part of that was spliting the delivberable in nova that actully need eventlet
vs those that dont

i.e. the command line clinets were monkey patched but never needed eventlet so those
were simple to seprate to remove the monkey patching
thats what https://review.opendev.org/c/openstack/nova/+/904424 does

the next step is to remove our use of eventlets thread pool and replace it with futureist's
version.
https://review.opendev.org/c/openstack/nova/+/922497/5
https://review.opendev.org/c/openstack/nova/+/905287/9
https://review.opendev.org/c/openstack/nova/+/917962/8

the third step is to remove the only usage of eventlet in the nova-api wsgi module

https://review.opendev.org/c/openstack/nova/+/905284/7

i may or may not have time to work on this in 2025.1

i will likely try to make some progress but i may need to hand this off to someone
else or rope in some other to help. if we can compelte what i had orginally
scoped in https://blueprints.launchpad.net/nova/+spec/eventlet-removal-part-1 for 2025.1
that woudl be a good first step.


next steps would be two fold.
first we need to change how spawn core service event loop by using the new backend being
added by https://review.opendev.org/c/openstack/oslo-specs/+/927503

second we need to change how we handel rpc requests.
when  the agent recives an rpc instest of executiong the function on the main thread we
need to dispatch that to either a GreenThreadPoolExecutor when we are monkey patched (using eventlet)
https://github.com/openstack/futurist/blob/master/futurist/_futures.py#L318
or a ThreadPoolExecutor https://github.com/openstack/futurist/blob/master/futurist/_futures.py#L99
when we are not usign eventlet.

that is requried so we can still have concurrent interleaved rpc processing and allow the
threaded version to just block waiting on future as needed.

that bit i have not figured out exactly where to do that yet.
but factoring out the rpc handling to use the executor interface would likely be eventlet-removal-part-2 (2025.2)
since that can be done without a dep onthe oslo.service change and then

eventlet-removal-part-3 2026.1 woudl be converting to the new oslo.servce backend and any remaining clean up.

that is optimistic and a lot of work so it may take longer or we might be able to start some other things earlier.

tehre is a lot of good work in https://wiki.openstack.org/wiki/Eventlet-removal#Migration_Plan also.

nova at present is not planning to use asynio  but that does nto mean we never will
we just dont have a high enough concurrence requireemtn to need it so trhead pools
shoud be sufficient

once we are using them there is no reaosn we coudl not have an AsyncioPoolExecutor
using awaitlet or explore using asyncio more directly

to your debugger point any servie that is not monkey patched will gain the ablity to just run
in a debugger normally i.e. once we get rid of using it in the api wsgi module you should be able to just
debug it but keep in mind that nova is a distributed system os if you set a breakpoint you will very likly
cause request to time out. debuging a distribute system is not the same as debuging a application running on
a single host and never will be.

that is not a goal of this work its just a side benifit.

>
> -Sylvain
>
> On Fri, 4 Oct 2024, 20:38 Herve Beraud, <hberaud@redhat.com> wrote:
> >
> > > We’re excited to share the latest updates on our ongoing efforts to phase
> > > out Eventlet across our various OpenStack projects. Below you’ll find a
> > > summary of our progress, key milestones, and important dates to keep in
> > > mind as we move forward with this critical initiative.
> > >
> > > ## Current Status
> > >
> > > We’ve completed the initial analysis phase across more than 120 OpenStack
> > > projects. This includes identifying the various patterns where Eventlet is
> > > currently in use and evaluating where it can be safely removed or disabled.
> > > Here are some highlights:
> > >
> > > - Completed Analysis: Projects where Eventlet is used include (but are
> > > not limited to): Aodh, Barbican, Nova, Neutron, Tacker, Taskflow, Trove,
> > > Venus, Watcher, and Zun.
> > >
> > > - Eventlet Optional: Several projects have been identified where Eventlet
> > > seems to be optional and can be disabled with minimal impact. For these
> > > projects, we will move forward the discussion with teams to try
> > > deactivating Eventlet in upcoming updates. Once done, projects of this kind
> > > would be able to start their migration with more serenity.
> > >
> > > - Eventlet Required: Some projects still rely heavily on Eventlet for
> > > core functionality. For these, we are going to develop specific migration
> > > plans.
> > >
> > > ## Migration Plans in Progress
> > >
> > > - oslo.db: Preparing its Asyncio based engine facade;
> > > - oslo.service: Refactoring plans being discussed to minimize disruption
> > > during the migration;
> > > - glance: Refactoring code to use native thread model rather than Eventlet
> > >
> > > More details can be found here:
> > > https://review.opendev.org/q/topic:%22eventlet-removal%22
> > >
> > > ## Latest Updates
> > >
> > > - Community Goal Transition: The ongoing community goal for removing
> > > Eventlet is now in the process of becoming an official "selected" goal,
> > > https://review.opendev.org/c/openstack/governance/+/931254.
> > >
> > > - Pattern Identification Completed: We’ve identified key patterns related
> > > to Eventlet usage, including its common integration with monkey_patch(),
> > > eventlet.Timeout, eventlet.GreenPool, and eventlet.wsgi.server(). Visit the
> > > official wiki to get more details
> > > https://wiki.openstack.org/wiki/Eventlet-removal#Identifying_Common_Pattern
> > >
> > > ## Important Dates
> > >
> > > - October 21st: cross PTG session.
> > > - October 23rd: cross PTG session (Q&A session and Open Discussion
> > > session)
> > >
> > > ## Call to Action
> > >
> > > We need your involvement to accelerate the progress of this initiative!
> > > If your project is affected by Eventlet, now is the time to start planning
> > > your migration. Teams are encouraged to take immediate steps in assessing
> > > how to deactivate Eventlet or to transition to alternative solutions.
> > >
> > > We defined key roles and responsibilities. Those will help us to lower
> > > the cost of the migration for our community. Teams are invited to assign
> > > them now. Being ready as soon as possible will allow you to better take
> > > advantage of the coming PTG sessions.
> > >
> > > Please find more details about these roles and their short terms tasks:
> > > https://wiki.openstack.org/wiki/Eventlet-removal#Roles_and_Responsibilities
> > >
> > > ## Final Thoughts
> > >
> > > This is a significant step forward for improving the stability,
> > > scalability, and maintainability of our projects. With your continued
> > > support, we’re confident that this migration will bring substantial
> > > benefits to the OpenStack community.
> > >
> > > If there are any questions or if you need assistance with your project’s
> > > transition away from Eventlet, please join the discussion on the
> > > #eventlet-removal channels (OpenStack irc, RedHat slack, mailing list).
> > >
> > > Thank you for your dedication and hard work!
> > >
> > > --
> > > Hervé Beraud
> > > Senior Software Engineer at Red Hat
> > > irc: hberaud
> > > https://github.com/4383/
> > >
> > >