Search results for "#eventlet-removal" - openstack-discuss

Re: [nova][eventlet-removal]Weekly sync video call

by Herve Beraud

Hey, Thanks for the update. I put your weekling meeting into the list of recurring events https://wiki.openstack.org/wiki/Eventlet-removal#Nova Will try to join when I can. Do you have an etherpad that you might want to also link there? Le mer. 11 juin 2025 à 09:22, Balazs Gibizer <gibi(a)redhat.com> a écrit : > Hi, > > The Nova core team agreed to have a weekly high bandwidth sync meeting > about the ongoing Eventlet removal work. Here are the details: > > [public]Nova Eventlet removal sync > > Every Wednesday: 14:30-15:00 UTC (16:30 – 17:00 CEST) > > Video call link: https://meet.google.com/bcy-uqoz-hje > > Cheers, > gibi > -- Hervé Beraud Principal Software Engineer at Red Hat irc: hberaud https://github.com/4383/

3 months, 1 week

Oslo Spec Review, Eventlet Removal Proposal.

by Daniel Bengtsson

Hi everyone, I hope you’re all doing well. During yesterday’s Oslo IRC meeting, the main topic was the removal of eventlet in oslo.service[1]. It seems that everyone is in agreement with this proposal, and no objections were raised. I would appreciate it if you could take another look and review the code. If we don’t receive any further objections by Monday, I propose we proceed with merging the spec. Thanks in advance for your help and feedback! [1] https://review.opendev.org/c/openstack/oslo-specs/+/927503?usp=dashboard -- Daniel Bengtsson Software engineer

10 months, 1 week

[nova][eventlet-removal]Weekly sync video call

by Balazs Gibizer

Hi, The Nova core team agreed to have a weekly high bandwidth sync meeting about the ongoing Eventlet removal work. Here are the details: [public]Nova Eventlet removal sync Every Wednesday: 14:30-15:00 UTC (16:30 – 17:00 CEST) Video call link: https://meet.google.com/bcy-uqoz-hje Cheers, gibi

3 months, 1 week

[oslo] status of eventlet removal for oslo.service?

by Chris Friesen

Hi everyone, Looking at the "epoxy" spec for removing Eventlet from oslo.service (https://specs.openstack.org/openstack/oslo-specs/specs/epoxy/remove-eventle…) the very top line is a link to search blueprints.launchpad.net. Following that link it seems like there is no blueprint for removing eventlet from oslo.service, so does the spec itself (with the proposed milestones) represent the current plan? Separately, is there somewhere that shows the progress on the threading backend for oslo.service? I see it exists, are there any limitations on the current implementation? Thanks, Chris

3 weeks, 4 days

[oslo] status of eventlet removal for oslo.service?

by Chris Friesen

Hi everyone, Looking at the "epoxy" spec for removing Eventlet from oslo.service (https://specs.openstack.org/openstack/oslo-specs/specs/epoxy/remove-eventle…) the very top line is a link to search blueprints.launchpad.net. Following that link it seems like there is no blueprint for removing eventlet from oslo.service, so does the spec itself (with the proposed milestones) represent the current plan? Separately, is there somewhere that shows the progress on the threading backend for oslo.service? I see it exists, are there any limitations on the current implementation? Thanks, Chris

3 weeks, 4 days

#eventlet-removal [ptg] 2025.2 Flamingo PTG summary

by Herve Beraud

Following the intensive discussions at the April 2025 Project Teams Gathering about the Eventlet removal initiative, this thread summarizes the current status, challenges, and strategies of all the OpenStack teams with a transversal perspective. A full and detailed report is available at: https://removal.eventlet.org/guide/openstack/flamingo-ptg/ ## Python 3.13 Compatibility The countdown has begun! As documented in the April 2025 PTG discussions, the OpenStack community is accelerating efforts to remove Eventlet dependencies across all projects. This initiative has become critical due to Eventlet's compatibility problems with Python 3.13 and the upcoming "GILectomy" (PEP 703). With Ubuntu 2025.4 planning to ship Python 3.13 by default, we're facing a hard deadline for this work https://discourse.ubuntu.com/t/plucky-puffin-release-schedule/36461 ## Migration Status ### Significant Progress - Octavia: Fully migrated since 2017! Their approach is now documented as a community case study. - Mistral: Almost there with a comprehensive migration approach. - Neutron: Significant progress with numerous patches already merged. - Glance: Can be deployed without Eventlet, though some optional features still need work. ### Work in Progress - Nova: Planning a service-by-service migration with dual-mode support during transition. - Swift: Evaluating alternatives with impressive performance results (FastWsgi showing 10x better performance!). - Manila, Cinder, Heat: All have active plans for the Flamingo cycle. - Designate, Blazar, Watcher: Starting their migration journeys. - Ironic: Facing complex challenges, particularly with the Ironic Python Agent component. ## Technical Spotlight: Oslo.service's Threading Backend A key development is the new threading backend for oslo.service that eliminates the Eventlet dependency: - Review in progress: https://review.opendev.org/c/openstack/oslo.service/+/945720 - No longer provides WSGI support - Each service will need to deprecate implementations dependent on Eventlet's WSGI server ## Migration Strategies: One Size Doesn't Fit All Projects are adopting diverse approaches: - Dual-mode support: Nova and Glance are supporting both Eventlet and native threads during transition - Canary approach: Swift is considering starting with proxy nodes - Component-by-component: Cinder is starting with the Volume Manager - Complete replacement: Heat is planning a full discontinuation of WSGI server implementations ## Nova's Detailed Roadmap Nova has a comprehensive two-cycle plan: Flamingo Cycle (2025.2): - API modernization - Architecture updates with environment variable controls - Performance improvements - Test transition to native threading Guppy Cycle (2026.1): - Core event loop conversion - Adoption of oslo.service's new threading backend ## Issues to Watch: RabbitMQ Heartbeat Problems The problem with RabbitMQ heartbeats story: - Timeouts and API failures in "green" environments - Partial solution using pthreads exists but has logging issues - Track the fix: https://review.opendev.org/c/openstack/oslo.log/+/937729 ## How to Get Involved - Join the #openstack-eventlet-removal channel on OFTC - Review the official guide: https://removal.eventlet.org/ - Look for patches under the "eventlet-removal" topic: https://review.opendev.org/q/prefixtopic:%22eventlet-removal%22 ## Recommended Reading For teams starting their migration: 1. Official goal documentation: https://governance.openstack.org/tc/goals/selected/remove-eventlet.html 2. Migration preparation guide: https://removal.eventlet.org/guide/preparing-for-migration/ 3. Octavia case study: https://removal.eventlet.org/guide/case-studies/octavia/ ## Stay Updated - The complete version of this report is available online at: https://removal.eventlet.org/guide/openstack/flamingo-ptg/ - Track the progress of the migration across all projects at: https://removal.eventlet.org/guide/openstack/#migration-status Thanks for reading! PS: This PTG summary is based on the etherpads following the April 2025 PTG discussions (https://ptg.opendev.org/etherpads.html) For more details, refer to the full report ( https://removal.eventlet.org/guide/openstack/flamingo-ptg/)

5 months

#eventlet-removal - HTTP SGI working group call for discussion

by Herve Beraud

tl;dr: We should have a cross discussion concerning the replacement of Eventlet.wsgi and we want to invite you to join the discussion and hence help us to define a standardized approach in a collaborative way. The Eventlet WSGI module can be used for 2 things: 1. as a WSGI server to serve any kind of web framework (flask, routes, etc...) [1] 2. and in some cases as a framework for web applications [2] Some OpenStack deliverables are using it in one way or another. Some deliverables like Glance already have credible migrations opportunities. But some of you may still be wondering what is your option to replace the Eventlet WSGI features? That's a good question. Now that the specs defining the removal of Eventlet from oslo.service are merged we have to define the way we want to proceed for the WSGI features. Indeed, we decided to drop the WSGI support from oslo.service. That means that we have to define, at least, a "default" way to replace it. If we want to avoid having multiple ways to manage things, we have to provide some guidance and standardizations. For this reason, after the PTG, we encouraged the creation of the HTTP SGI Working Group [4]. This working group aim to answer which (W|A)SGI servers are needed or credible alternatives. Which framework we have/want/need to use in parallel with the SGI server. The outcomes created by this group will serve as "a default" to guide the community through the replacement of the WSGI features of Eventlet. We prepared comparisons of the available alternatives for each layer: - https://wiki.openstack.org/wiki/SGI-servers-comparison - https://wiki.openstack.org/wiki/web-frameworks-comparison - https://wiki.openstack.org/wiki/Http-libraries-comparison Feel free to comment and to put your pros and cons on the given related etherpads (see the links in the comparison). This topic will be discussed at each irc meeting on the #openstack-eventlet-removal channel [5], until we find a default official option. Next meeting date is: 2024 December 3rd [6]. It would be good to reach an official consensus before the Milestone 3 of Epoxy. The goal is simply to ensure that our community looks in the same direction and that everyone is on the same page. We want to ensure that nobody is left behind. Feel free to reply to this thread or to put your comments directly on the various etherpads [6][7][8][9]. Thanks for reading. [1] https://eventlet.readthedocs.io/en/latest/reference/api/eventlet.html#modul… [2] https://eventlet.readthedocs.io/en/latest/modules/wsgi.html [3] https://review.opendev.org/c/openstack/oslo-specs/+/927503 [4] https://wiki.openstack.org/wiki/Eventlet-removal#The_HTTP_SGI_Working_Group [5] https://meetings.opendev.org/meetings/openstack_eventlet_removal/ [6] https://etherpad.opendev.org/p/epoxy-eventlet-tracking [7] https://etherpad.opendev.org/p/eventlet-removal-SGI-servers-comparison [8] https://etherpad.opendev.org/p/eventlet-removal-web-frameworks-comparison [9] https://etherpad.opendev.org/p/eventlet-removal-http-libraries-comparison -- Hervé Beraud Senior Software Engineer at Red Hat irc: hberaud https://github.com/4383/

10 months

Re: [oslo] status of eventlet removal for oslo.service?

by Jay Faulkner

oslo.service supports threading now; see https://docs.openstack.org/oslo.service/latest/user/backend.html for detail on exactly how. There are some limitations, primarily oslo_service.wsgi is retired. Ironic is eventlet-free based on these (and other) oslo changes; as a former oslo_service.wsgi user we changed to cheroot to play that role for us. -JayF On 8/27/25 7:32 AM, Chris Friesen wrote: > Hi everyone, > > Looking at the "epoxy" spec for removing Eventlet from oslo.service > (https://specs.openstack.org/openstack/oslo-specs/specs/epoxy/remove-eventle…) > the very top line is a link to search blueprints.launchpad.net. > > Following that link it seems like there is no blueprint for removing > eventlet from oslo.service, so does the spec itself (with the proposed > milestones) represent the current plan? > > Separately, is there somewhere that shows the progress on the > threading backend for oslo.service? I see it exists, are there any > limitations on the current implementation? > > Thanks, > Chris

3 weeks, 4 days

#eventlet-removal Flamingo PTG

by Herve Beraud

Hello folks, We’re meeting again on the Project Teams Gathering in April (7-11th). The slot for the Eventlet Removal Initiative PTG is: Tuesday (Apr 8) 1400-1600 UTC The etherpad is: https://etherpad.opendev.org/p/apr2025-ptg-eventlet Please feel free to insert your topic proposals. Additional details can be found at https://ptg.opendev.org/ Regards, -- Hervé Beraud Senior Software Engineer at Red Hat irc: hberaud https://github.com/4383/

5 months, 3 weeks

#eventle-removal - Progress & Updates Epoxy Milestones 2-3

by Herve Beraud

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 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? ## 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://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/

7 months, 1 week

openstack-discuss search results for query "#eventlet-removal"