On 2/11/25 6:58 PM, Herve Beraud wrote:

Today we wanted to share with you 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 continue to move forward with this critical initiative.

## Current Status

The lib freeze is next week and we are close from milestone 3. At the time I wrote these lines 105 eventlet removal patches have been submitted on our gerrit and 61 patches are now merged. That shows really good progress.

https://review.opendev.org/q/prefixtopic:%22eventlet-removal%22 <https://review.opendev.org/q/prefixtopic:%22eventlet-removal%22>

Eventlet is now in version 0.39.0 and is compatible and ready to be used with Python 3.13, meaning that we are ready for an upgrade of our runtimes within the coming series.

## Achievements

Among all the contributions, we can highlight these achievements:

- 2 deliverables are now completely migrated: python-manilaclient and mistral-lib; - Neutron implemented their new socket server in replacement of the eventlet WSGI features and they started to migrate their OVN agent other that new server; - Mistral has made excellent progress and significantly reduced their usages of Eventelt. From moving from coroutines to threading, or migrating their messaging executor. We will been soon able to consider mistral as fully migrated; - Glance started a wide clean up of Eventlet into their functional tests; - oslo.service's backend mechanism is now implemented and the Eventlet isolation as been merged, opening the door of its refactoring based on threading; - Almost all Oslo deliverables (apart oslo.vmware) deprecated Eventlet from their usages; - Eventlet's support of Python 3.13 has been implemented and released; - Eventlet stabilization works have been done during the past months and we now observe less negative feedback and less new bugs. No news, good news; - The community goal is now selected, officializing the starting of this initiative.

## Latest Updates

There are side conversations concerning the deprecation/removal of oslo.rootwrap and oslo.vmware. Those both deliverables rely on Eventlet and are in some way considered as deprecated or experimental.

In parallel to that, we think we should also have a discussion about heat and heat-templates. The activity of these projects seems quite slow and (do not hesitate to correct me if I'm wrong) they are more or less in a way to be replaced with more modern ways to orchestrate OpenStack. Should we not prioritize their deprecation or at least start a wider discussion about their fate?

Well, I'm quite surprised to see this statement without any discussion with the heat project, or even me who has been maintaining the project for some time. Yes. Heat is not very active. However it is used in multiple deployments or products. The User survay data[1] shows 57% of deployment is using heat. I know there are several vendors using it in their product. However the sad fact is that most of them rarely prioritize improvement or even maintenance of Heat recently. [1] https://www.openstack.org/analytics/ I've seen number of people insisting that Heat can be "easily" replaced by any other "much better" tools such as ansible. Yes. It may be easy to create resources using such tools, but you likely find multiple problems when you try to modify your resource stacks, like reducing number of servers. You should be always careful about the resource dependencies (for example you can not delete a volume before you detach it from an instance) and implementing the correct dependency is usually messy unless your tool can detect diff and construct the appropriate order of resource update, which heat does. I saw number of softwares, especially NFV managers, were built on Heat in the past and I don't know how many of these could have migrated away from heat really. However I'm happy to retire it if there is a common consensus within the community that heat is no longer a thing and can be easily replaced by something much better. I'm quite interested in learning what 57% of deployments may use next to replace heat, so that I know what I can/should focus instead of Heat (or even OpenStack) :-) .

## Call to Action

Epoxy is a SLURP series, and as we are close from lib freeze and from milestone 3, that's the right time to prioritize your deprecations in your deliverables in view of removing these pieces with non-SLURP series. The sooner they are deprecated the better.

## Important Dates

Please do not hesitate to join us during our bi-weekly meeting on #openstack-eventlet-removal. Bring your own topics and do not hesitate to ask questions.

All the details are available in the links below: - https://wiki.openstack.org/wiki/Eventlet-removal#Recurring_Events <https://wiki.openstack.org/wiki/Eventlet-removal#Recurring_Events> - https://etherpad.opendev.org/p/epoxy-eventlet-tracking <https://etherpad.opendev.org/p/epoxy-eventlet-tracking>

## Final Thoughts

This series strongly demonstrated the feasibility to remove our dependency to Eventlet. There is still a long way to go but the path is now well cleared. Do not hesitate to take example on the ongoing efforts, and If there are any questions or if you need assistance with your project’s transition away from Eventlet, please join the discussion on the #openstack-eventlet-removal OFTC channels . We will be happy to help you!

Thank you for your dedication and hard work!

-- Hervé Beraud Senior Software Engineer at Red Hat irc: hberaud https://github.com/4383/ <https://github.com/4383/>