On 17/06/2025 18:52, Herve Beraud wrote:
I think there is an option C.
Since the beginning of this initiative, the goal has always been to phase out Eventlet cleanly from OpenStack components, particularly Nova. The initial proposal targeted the 2027.2 release, at a time when Nova had no plans to support a dual concurrency model. At that point, Eventlet removal was not classified as a feature removal subject to SLURP policy - it was considered an internal refactoring, with no addition of transitional features requiring later removal. The idea was to deprecate any Eventlet-related features, public APIs, and configuration options as early as possible. As a result, SLURP policy constraints were not a primary concern.
But the situation has evolved. Nova has now committed to offering a full release cycle (2027.1) where both concurrency models - Eventlet and threading - are supported. This is not a technical convenience, but a response to explicit operator requests: operators want the ability to switch concurrency modes outside in case of problem during at least one series. The full threading support in Nova will not be ready before 2026.2, which is a non-SLURP release, and that the dual-mode support must be preserved throughout 2027.1.
unless this has changed since the ptg we were hoping for the first release to supprot runign without eventlet to be 2026.1 and the defautl to chagne in 2026.2. so 2026.1 would be the slrup release where operator woudl chage to eventlet before upgrading to 2027.1
However, current SLURP policy requires that a removal can only happen in a SLURP release.
That is incorrect. deprecation can only happen in slurps removals can happen in either provided the feature is deprecated in the prior slurp.
According to Nova's plan that excludes a removal in 2027.1.
that is also incorrect removal is only exclded if we dont get to full threadign supprot in 2026.1 we have not deprecated evenlet supprot yet and we dont plan do do that formally until we have show that nova can work without it.
If we follow the rules strictly, Eventlet removal would be delayed to 2028.1, adding several months of dual-mode support, increased maintenance complexity, and growing technical debt. again this is very much misrepresenting the current plan.
From a technical standpoint, it’s important to highlight that upcoming Python versions (3.14 and 3.15) introduce major changes to the GIL [1], threading behavior, and RLocks - all areas [2] that have historically been problematic in Eventlet. We’ve already had to implement significant patches for Python 3.13. There is also uncertainty around which Python versions will be adopted by the various Linux distributions and by our own supported runtime environments, making long-term compatibility assumptions with Eventlet increasingly risky, but in all the cases it will put additional pressure on us. Continuing to support Eventlet until 2028 is effectively betting on the stability of a module that is already on life support, with very few contributors available to maintain it beyond 2027 (see Jay's note about GR-OSS). More critically, there is no guarantee today that Eventlet, in its current state, will remain robust enough to reliably support a fallback path in case a regression forces a rollback from threading to Eventlet.
This is why I propose a pragmatic and balanced compromise: we maintain the planned deprecation (we might have to adjust a little bit those from oslo), but we make a documented and limited exception to allow Eventlet removal in 2027.2, which is a non-SLURP cycle. This exception would be coordinated with the Technical Committee and the release team and is justified by:
- the commitment made by Nova to offer a full cycle of dual-mode support in 2027.1;
again that was not what we commited too. we aim to provide that in 2026.1 if we dont make that teh deprecation fo eventlet supprot will slip to 2026.2 and we will supprot both in 2027.1 and do the removal in 2027.2. supprot for eventlet in 2027.1 is predicated in not completeing the work in 2026.1.
- the high technical cost of maintaining dual concurrency models; - the fast evolution of Python and the increasing risk of incompatibilities with Eventlet; - the limited engineering resources available to sustain Eventlet maintenance; - and the need to align with operator expectations while still securing the long-term health of the platform.
This approach gives Nova the entire 2027.1 cycle to deliver a complete and stable dual-mode implementation, as promised to operators. At the same time, it enables the rest of the ecosystem to move forward safely, without relying on a dependency that is increasingly brittle and obsolete.
In large open source projects, it is not uncommon for policies to be temporarily adjusted in the face of structural or technical emergencies. This is not a convenience exception - it’s a reasoned and responsible deviation from the norm, driven by necessity.
For this reason I add the release team and the TC to the party. Please share your feedback with us.
[1] https://docs.python.org/es/dev/whatsnew/3.14.html#whatsnew314-free-threaded-... [2] https://docs.python.org/es/dev/whatsnew/3.15.html#threading.
Le lun. 16 juin 2025 à 18:06, Sean Mooney <smooney@redhat.com> a écrit :
On 16/06/2025 15:33, Dmitriy Rabotyagov wrote: > Also let's keep in mind, that only nova (with placement) will spawn 64 > threads on such setup by default.
yep see my other reply.
you mixign up workers and eventlet threads.
those are two very diffent things.
we likely shoudl change the upstream default for workers to 1.
we do tend to override that by defualt in installer tools.
> > And then all really depends on set of services to launch on such setup. > > So from deployment tooling protective you have all required data to > rollout not instantly oom-ing setup at cost of amount of request > services can process in parallel. > > On Mon, 16 Jun 2025, 15:24 Dmitriy Rabotyagov, > <noonedeadpunk@gmail.com> wrote: > > In case you try to use a 32gb box with 16 cores as a controller > for OpenStack - it will blow off with default amount of workers > for wsgi and /or eventlet apps. > > While you can argue this should not be used as production setup, > this can be totally valid for sandboxes and we wanna provide > consistent and reliable behavior for users. > > But my argument was not in if/how we want to fine-tune > deployments, but also understand and provide means to define > what's needed as well as potential ability to revert in worst case > scenario as a temporary workaround. > So still some variables and logic would be introduced from what I > understand today. > > > On Mon, 16 Jun 2025, 14:43 Sean Mooney, <smooney@redhat.com> wrote: > > > On 16/06/2025 13:27, Dmitriy Rabotyagov wrote: > > > > > > > > sayint its FUD is not helpful. > > > > we got a driect ask form operator and soem core to not > do a hard > > switch > > over. > > > > and while i wanted to only support one model for each > binary at a > > time > > we were sepcificly ask to make it configurable. > > > > > In the later case, your only available action is help > fixing > > bugs. It > > > is not up to the operators to double-guess what may or > may not > > work. > > > > correct we are not planning to document how to change > mode we were > > planning to only use this configuration in ci and > operator would be > > > > > > Well, we'd need to have that communicated so that deployment > toolings > > could adopt their setup to changes, as, for instance, in OSA > amount of > > eventlet workers are calculated based on the system facts, > so we'd > > need to change the logic and also suggest how users should > treat this > > new logic for their systems. > > why is OSA doing that at all today? > we generally don't recommend changing those values from the > default > unless you really know what your doing. > i don't think other installer do that. > tripleo, kolla-ansbile and our new golang based installer do > not, nor > does devstack so its surprising to me that OSA would change > such low > level values > by default. > > we will document any new config options we and and we are > documentation > how to tune the new options for thread pools but we do not expect > installation > tools to modify them by default. we are explicitly not making the > options based on the amount of resources on the host i.e. > dynamically > calculated based > on the number of CPU cores. > > for example we are explicitly setting the number of > scatter_gather > thread in the the dedicated thread pool to 5 > why its a nice small number that will work for most people out > of the box. > > can you adjust it, yes but it scale based on the number of > nova cells > you have an 99% wont have more then 5 cells. > > using information about the host where the API is deployed to > infer the > value of that would be incorrect. > > you can really only make an informed decision about how to > tune that > based on monitoring the usage of the pool. > > that how we expect most of the other tuning options to go as well. > > our defaults in nova tend to be higher then you would actually > need in a > real environment so while it may make sense to reduce > them we try to make sure the work out of the box for most people. > > gibi id building up > https://review.opendev.org/c/openstack/nova/+/949364/13/doc/source/admin/con... > > as part of nova move to encode this but our goal is that > deployment > tools shoudl not need to be modifyed to tune these > valued by defualt. > > > > > So it will be kinda documented in a way after all. > > > > > > told for a given release deploy this way. > > > > this is an internal impelation detail however we are not > prepared to > > deprecate usign eventlet until we are convicned > > > > that we can run properly without it. > > > > > For beginners, this would be a horrible nightmare if > default > > options > > > simply wouldn't work. We *must* ship OpenStack working > by default. > > no one is suggesting we do otherwise. > > > > > > Cheers, > > > > > > Thomas Goirand (zigo) > > > > > >
-- Hervé Beraud Principal Software Engineer at Red Hat irc: hberaud https://github.com/4383/