I'm confused a bit -- the implementation details of our threading modules are not a public API that we owe deprecation periods for. Why are we treating it as such? -JayF On Fri, Jun 13, 2025 at 11:02 AM Sean Mooney <smooney@redhat.com> wrote:
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
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
and what the impact will be for projects that do not finish work as per
not started the the goal doc for the exact timelines the timelines (for example upgrade
issue, workaround etc).
[1] https://governance.openstack.org/tc/goals/selected/remove-eventlet.html#comp...
-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