On 13/06/2025 16:55, Ghanshyam Maan wrote:
> ---- On Fri, 13 Jun 2025 08:33:25 -0700 Jay Faulkner <jay@gr-oss.io> wrote ---
> >
> > On 6/13/25 5:08 AM, Balazs Gibizer wrote:
> > > Hi Stackers!
> > >
> > > I would like to sync about the planned timeline of dropping eventlet
> > > support from OpenStack / Oslo.
> > >
> > > Nova definitely needs at least the full 2026.1 cycle to have a chance
> > > to transform the nova-compute service. But this plan already feels
> > > stretched based on the progress in the current cycle. So being
> > > conservative means we need the 2026.2 cycle as a buffer.
> > >
> > > Nova would like to keep a release where we support both eventlet and
> > > threading in parallel. So that operators can do the switching from
> > > eventlet to threading outside of the upgrade procedure. (This was an
> > > explicit request from them during the PTG). So 2026.2 could be that
> > > version where nova fully supports both concurrency mode, while
> > > eventlet can be marked deprecated. Then the 2027.1 release could be
> > > the first release dropping eventlet.
> > >
> > > However we need to align with the SLURP upgrade as well. 2026.1 is a
> > > SLURP. But in that release Nova might not be ready to have all
> > > services running in threading mode. So the 2026.1 - 2027.1 SLURP
> > > upgrade would force the operators to change the concurrency mode
> > > during the upgrade itself.
yes i think that how it should work if an only if a givne service is
capable of
working without eventlet in the prior slurp.
if we dont get to the point of being able to run in threaded mode for a
given service
in 2026.1 then the deprecate of eventlet for tha service will have to be
released in the next slurp
(2027.1) before the removal of support can be done in the next non slupr
2027.2
> > >
> > > I see two ways forward:
> > > * A) We say that operators who want to do the concurrency mode change
> > > outside of an upgrade could not skip the 2026.2 release, i.e. they
> > > cannot do SLURP directly from 2026.1. to 2027.1.
>
> This has a big impact on upgrades and breaks our SLURP model.
>
> > > * B) We keep supporting the eventlet mode in the 2027.1 release as
> > > well and only dropping support in 2028.1.
no we can support it in 2027.1 with all serives defaulting ot not using
it if
its congurable and deprecate it then remove in 2027.2
we do not need to extned to 2028.1
>
> I am in favour of this option.
>
> I was reading the goal doc about the timeline and found something in
> 'Completion Criteria' section[1] which says:
> - (2027.1) Get usage of Eventlet in oslo deliverables removed;
so in my mind 2027.1 was either gonig to be the first release without
eventlet support
or the last release to supprot eventlet mode.(if supported in 2027.1
eventlet mode would not be the default mode
and would be deprecated for removal in 2027.2.
my expectation is the first release of nova to support running in thread
mode would be 2026.1
but im not convinced we will be confident enough to switch threaded mode
on by default
for all nova services in 2026.1. basically i think it may be funcitonal
but have some bugs or performace issues
that will be refined in 2026.2 wehre we will look to change the default.
then in 2027.1 we will either start removing the option to run in
eventlet mode
or deprecate that and remove it in 2027.2
my logic is this if we can run in threaded mode in 2026.1 in all service
we will likely deprecate
eventlet mode in 2026.1, but im not sure we will change the default and
deprecate in the same release.
nova may decied to take a per bindary (api vs schduler) approch to
changing the default and doign the eventlet
removal too but we have not discussed that in detail.
for example if the nova-schduler is able to run in thread mode this
cycle. we could deprecate runing
it in eventlet mdoe in 2026.1 and make threaded mode the default however
we will still need eventlet for nova-compute.
so we have a choice to make, only deprecate using eventlet in nova once
all nova service are ready
or do it per sevice as each part is ready.
> - "(2027.2) Get Eventlet retired from OpenStack;"
> Again, 2027.2 (non-SLURP) is mentioned as eventlet retirement, I do not know
> if any technical reason to do it in non-SLURP or it can be moved to SLURP release.
> Maybe hberaud knows.
i dont see doing this in a non slurp as a problem under our upgrade policy.
once we have supprot for runnign without it in a preor slurp even if its
not the defautl we
are free to deprecate eventlet supprot in that slurp and remove it in a
non slurp.
to me this jsut reads as we deprecate in 2027.1 annoching it will be
removed in a future release
adn then we do the removal in the non slurp
i think doing the actual removal in a non slurp is better then doing it
in a slurp.
i.e. the deprecations happen in the slurps, the changes of defaults and
remvoal of code happens in the non slurps.
operators who want to move fast or use newer python release can adopt
the new defaults earlier in the non sluprts
those that want to move slow get longer for the new mode to bake by
skiping the release and getting the concuracy
model change on upgrade.
>
> Anyway, thanks gibi for bringing this. There are many projects that have not started the
> work yet (Nova might have more work compared to others), but I think we should discuss/re-discuss
> the timelines considering all projects/challenges. Accordingly, update the goal doc for the exact timelines
> and what the impact will be for projects that do not finish work as per the timelines (for example upgrade
> issue, workaround etc).
>
> [1] https://governance.openstack.org/tc/goals/selected/remove-eventlet.html#completion-criteria
>
> -gmaan
>
> >
> > Keeping eventlet running for that long is not something that is a worthy
> > investment of time. The oslo libraries are showing a deprecation of
> > 2026.2, I've been using that date as the target for all Ironic work as
> > well.
> >
> > Beyond the oslo team (who I don't speak for), there are folks -- like
> > Itamar on behalf of GR-OSS -- who are doing work behind the scenes to
> > keep eventlet running - barely. I do not expect the GR-OSS investment in
> > this work to extend much past the midpoint of 2026.
> >
> >
> > My $.02,
> >
> > Jay Faulkner
> > Open Source Developer
> > G-Research Open Source Software
> >
> >
>