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

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

10 months, 3 weeks

[ptg] #eventlet-removal 2026.1 Gazpacho PTG summary

by Herve Beraud

Hi everyone, Following our last week PTG meeting, I’d like to share a brief summary of the key outcomes, achievements, and next steps we agreed upon for the Eventlet removal initiative. ## Flamingo Retrospective We have crossed an important milestone: over 50% of impacted projects have shown significant migration progress. 19 deliverables are fully migrated, while 32 others are currently undergoing migration work. Here are the main accomplishments delivered during Flamingo: - Eventlet now includes support for Python 3.14, ensuring compatibility with upcoming Python releases; - Oslo.service introduced a new threading backend to provide a fully threading-based execution model; - Ironic, Heat, Barbican, Mistral, and several other projects are now fully migrated; - the Neutron migration is just one step away from completion; - Nova-api, nova-metadata-api, nova-conductor nova-scheduler can now run in threading mode. ## Gazpacho Call to Actions The following actions are expected to structure our efforts for the Gazpacho development cycle: - we must enhance oslo.service to prevent fork-inherited lock deadlocks by defaulting to the spawn multiprocessing start method, which will address known Manila and Cinder bugs; WIP https://review.opendev.org/c/openstack/oslo.service/+/963742 - we are preparing to merge the new opt-in H905 hacking rule to ensure consistent Eventlet usage detection across all OpenStack projects (see: https://review.opendev.org/c/openstack/hacking/+/959699) - we should clean up the bug tracker of migrated projects to reflect the current status of the eventlet removal efforts. Many of those projects surely have historical eventlet bugs that could be closed; - we need to maintain momentum on ongoing migrations and accelerate progress on the most delayed projects; - we should prioritize the “low-hanging-fruit” migrations, such as Cyborg and Magnum. ## Project Needing Attention Several projects have not shown any notable update during this cycle and require focus in the next series. These projects still contain Eventlet occurrences that must be addressed urgently: Blazar, Venus, Tacker, Masakari, and Zun. The TC has marked Venus and Vitrage as inactive, and these teams may be retired in 2026.2 if activity does not resume. ## Open Discussion Nova plans to focus on nova-compute, nova-novncproxy, testing improvements, and Rally-based benchmarking to fine-tune thread pool defaults, making Gazpacho the likely cycle where Nova fully switches from Eventlet to threading. Dan Smith presented a strategy idea for Glance that we could name the “Optional Eventlet Shim Strategy.” The goal of this approach is to make the use of Eventlet fully optional, allowing Glance to run without this dependency by default. To achieve this, all Eventlet-related code would be isolated outside of Glance’s core and moved into a separate module acting as a bridge. The core of Glance would remain unique and free of any references to Eventlet. If users still wish to rely on Eventlet, they would be able to install an additional module that provides the required implementation. Without this module, Glance would naturally run using the native threads concurrency mode. This approach offers a smooth transition path while preserving the ability to revert if needed, ultimately moving Glance toward a fully Eventlet-free architecture. Thank you to everyone who contributed during the PTG discussions and for the continuous efforts across teams. Let’s keep the momentum going as we enter the Gazpacho cycle and move closer to a fully Eventlet-free OpenStack. As always, you’re welcome to join us on IRC at #openstack-eventlet-removal, and you can find guidance, resources, and updates at https://removal.eventlet.org/ Thanks for your attention. -- Hervé Beraud Principal Software Engineer at Red Hat irc: hberaud https://github.com/4383/

1 month, 4 weeks

#eventlet-removal - PTG October 2024 Summary

by Herve Beraud

Last week was the OpenStack PTG. The Eventlet removal initiative ran two PTG sessions. The first session [1] was a presentation of the initiative, where the second session [2] was a technical open discussion. Please find out below the main key points and the proposed answers. ## Key Points The first key point made during these PTG sessions is that without consistency in our choices and decisions we will create more complexity than anything else. It is crucial to avoid having multiple ways to start services across different projects. A unified approach will simplify maintenance and enhance user experience. Leading us to the following questions: - how to remove the WSGI features provided by Eventlet and how to move to another HTTP server (WSGI/ASGI); - how to manage tasks. The WSGI/HTTP server discussion just come in time with the proposal made by Stephen Finucane to Deprecate/remove non-uWSGI deployment mechanisms from Devstack: https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack… We think that this topic overlaps with the WSGI aspects of Eventlet removal, for this reason, with the aim to answer these questions we propose to create specialized working groups (see the section below). We also made comparisons between available alternatives, here is an example with the SGI question https://wiki.openstack.org/wiki/SGI-servers-comparison. Find out all our comparisons in the official wiki page: https://wiki.openstack.org/wiki/Eventlet-removal#The_HTTP_SGI_Working_Group ## Specialized working groups The main role of these working groups is to avoid having multiple ways to manage things. Groups would be responsible for producing a unified approach that will simplify maintenance and enhance user experience. Our discussions have brought out 3 specialized working groups: - The HTTP SGI Working Group - The Tasks/Process Working Group - The Architecture, Interoperability and Technical Standardization Working Group If you are interested in one or many of these specialized working groups, then, please raise your hand and join the discussions. Please also take a look to the official page: https://wiki.openstack.org/wiki/Eventlet-removal#Specialized_Working_Groups… ## Latest Updates - Glance took full advantage of the PTG discussion. They got an overview of their WSGI migration options and they gain a better understanding of their current situation (https://etherpad.opendev.org/p/oct2024-ptg-glance#L277) and the Glance team were able to set up a migration plan: https://etherpad.opendev.org/p/oct2024-ptg-glance#L340 - Ironic Python Agent (IPA), is also experimenting about their Eventlet removal, their works is strongly related to the WSGI feature replacement: https://review.opendev.org/c/openstack/ironic-python-agent/+/924634 - The threading executor of oslo.messaging could shorten our migration path concerning the RPC aspects. For this reason we proposed to start the deprecation of the Eventlet executor within oslo.messaging. https://review.opendev.org/c/openstack/oslo.messaging/+/933399 - Another topic that arose during the PTG is how to manage timeouts. Some proposal have been made, they propose to rely on SQLAlchemy or Ceph to handle timeout management: https://etherpad.opendev.org/p/oct2024-ptg-eventlet-removal#L103 https://etherpad.opendev.org/p/oct2024-ptg-os-tc#L298 ## Important Dates Nov. 5th is the first IRC meeting on #openstack-eventlet-removal, do not hesitate to join us. We will cover all the topics addressed in this mailing thread. ## SLURP vs non-SLURP The PTG sessions came with timeline and cadence discussions. For this reason we made some proposal about workload regulation: https://wiki.openstack.org/wiki/Eventlet-removal#Workload_regulation_2 In substance we propose to base our cadence on SLURP and non-SLURP releases. Epoxy is a SLURP release, for this reason we should not expect breaking changes happening during this series, however, SLURP series are good opportunities to deprecate things, remove useless workaround, and start small clean up in preparation of wider changes. ## Final Thoughts We strongly encourage a collaborative selection of our candidate(s) for HTTP server replacement .This selection will dictate how we deal with server gateway interfaces for the coming decade, so we should focus our coming discussion on this specification, for this reason we invite you to join the specialized working groups. Thanks to all the people who joined the various discussions. Thank you for your dedication and hard work! [1] https://etherpad.opendev.org/p/oct2024-ptg-os-tc#L195 [2] https://etherpad.opendev.org/p/oct2024-ptg-eventlet-removal -- Hervé Beraud Senior Software Engineer at Red Hat irc: hberaud https://github.com/4383/

1 year, 2 months

#eventlet-removal - Progress & Update

by Herve Beraud

We’re excited to share 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 move forward with this critical initiative. ## Current Status We’ve completed the initial analysis phase across more than 120 OpenStack projects. This includes identifying the various patterns where Eventlet is currently in use and evaluating where it can be safely removed or disabled. Here are some highlights: - Completed Analysis: Projects where Eventlet is used include (but are not limited to): Aodh, Barbican, Nova, Neutron, Tacker, Taskflow, Trove, Venus, Watcher, and Zun. - Eventlet Optional: Several projects have been identified where Eventlet seems to be optional and can be disabled with minimal impact. For these projects, we will move forward the discussion with teams to try deactivating Eventlet in upcoming updates. Once done, projects of this kind would be able to start their migration with more serenity. - Eventlet Required: Some projects still rely heavily on Eventlet for core functionality. For these, we are going to develop specific migration plans. ## Migration Plans in Progress - oslo.db: Preparing its Asyncio based engine facade; - oslo.service: Refactoring plans being discussed to minimize disruption during the migration; - glance: Refactoring code to use native thread model rather than Eventlet More details can be found here: https://review.opendev.org/q/topic:%22eventlet-removal%22 ## Latest Updates - Community Goal Transition: The ongoing community goal for removing Eventlet is now in the process of becoming an official "selected" goal, https://review.opendev.org/c/openstack/governance/+/931254. - Pattern Identification Completed: We’ve identified key patterns related to Eventlet usage, including its common integration with monkey_patch(), eventlet.Timeout, eventlet.GreenPool, and eventlet.wsgi.server(). Visit the official wiki to get more details https://wiki.openstack.org/wiki/Eventlet-removal#Identifying_Common_Pattern ## Important Dates - October 21st: cross PTG session. - October 23rd: cross PTG session (Q&A session and Open Discussion session) ## Call to Action We need your involvement to accelerate the progress of this initiative! If your project is affected by Eventlet, now is the time to start planning your migration. Teams are encouraged to take immediate steps in assessing how to deactivate Eventlet or to transition to alternative solutions. We defined key roles and responsibilities. Those will help us to lower the cost of the migration for our community. Teams are invited to assign them now. Being ready as soon as possible will allow you to better take advantage of the coming PTG sessions. Please find more details about these roles and their short terms tasks: https://wiki.openstack.org/wiki/Eventlet-removal#Roles_and_Responsibilities ## Final Thoughts This is a significant step forward for improving the stability, scalability, and maintainability of our projects. With your continued support, we’re confident that this migration will bring substantial benefits to the OpenStack community. If there are any questions or if you need assistance with your project’s transition away from Eventlet, please join the discussion on the #eventlet-removal channels (OpenStack irc, RedHat slack, mailing list). Thank you for your dedication and hard work! -- Hervé Beraud Senior Software Engineer at Red Hat irc: hberaud https://github.com/4383/

1 year, 2 months

Re: Oslo Spec Review, Eventlet Removal Proposal.

by dbengt＠redhat.com

On 11/14/24 11:01 AM, Daniel Bengtsson <dbengt(a)redhat.com> wrote: > 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. As planned, the patch was merged yesterday, and we will soon start working on the implementation.

1 year, 1 month

Re: #eventlet-removal - Progress & Updates - Flamingo milestone 1

by Dmitry Tantsur

Hi! Thank you for the update, here is the etherpad I created for Ironic: https://etherpad.opendev.org/p/ironic-eventlet-removal Dmitry On 5/20/25 6:44 PM, Herve Beraud wrote: > TL;DR: We just passed the milestone 1 of Flamingo and at this point big > fishes like Neutron, Nova, Glance, and Mistral demonstrated awesome > progress in their migration. Oslo.service's new backend is now usable in > real life use cases. Eventlet still suffers from a new version of > Python. If you have not yet started your migration yet, then, please > consider starting ASAP before the aircraft crash. > > ## OpenStack Updates > > Neutron's L3 agent is well on its way to running its WSGI features > without using Eventlet and activating the new oslo.service threading > backend at runtime. Allowing to decouple a bit more the needs of > Eventlet at runtime. > > Nova scheduler is now able to start in threading mode without requiring > any usage of Eventlet at runtime. This was possible by also shifting > nova-scheduler to the threading backend of oslo.service. More details > are available here https://gibizer.github.io/categories/eventlet/ > <https://gibizer.github.io/categories/eventlet/> > > Activating the new threading backend of oslo.service required devstack > adaptation to allow having jobs running this execution mode. https:// > review.opendev.org/c/openstack/devstack/+/948436 <https:// > review.opendev.org/c/openstack/devstack/+/948436>. Everybody will be > able to benefit from these adaptations. > > Glance continues its adaptation journey by migrating its functional jobs > to reduce its needs of Eventlet and to allow it to run jobs in threading > mode. > > oslo.service's new backend is on the way to be landed soon, and is > waiting for additional reviews. https://review.opendev.org/c/openstack/ > oslo.service/+/945720 <https://review.opendev.org/c/openstack/ > oslo.service/+/945720> > > ## Eventlet Updates > > Our CI was failing for almost 2 months, we were able to unlock this > failing CI and hence we were able to merge several blocked reviews. > > Last week Eventlet 0.40.0 was released. This new version provides fixes > around OpenSSL 3.5+. > The support of Python 3.8 and of PyPy were removed. > > The Python 3.13 issues are still not solved and require further work. > > ## Call to Action > > Flamingo is a crucial series in the realization of global migration of > OpenStack. We need your involvement to accelerate the progress of this > initiative! > > If your project is affected by Eventlet, now is the time to start your > migration. Teams are invited to read the migration guide available at > https://removal.eventlet.org/ <https://removal.eventlet.org/> and are > encouraged to join the #openstack-eventlet-removal IRC channel to get help. > > You'll benefit quickly from the advantages of running your deliverables > without using Eventlet. > > ## Final Thoughts > > Postponing the beginning of the migration will put additional pressure > related to growing runtime failures of Eventlet. We want to prevent this > from happening to you. > > We are now going straight to milestone 2 meaning that we will soon be in > the middle of Flamingo. > > The migration path is now well cleared by all the previous actions and > changes applied into OpenStack. Do not be afraid by the migration and > take advantage of the collected experience. > > Your journey start here https://removal.eventlet.org/ <https:// > removal.eventlet.org/> > > Thanks for reading. > > -- > Hervé Beraud > Principal Software Engineer at Red Hat > irc: hberaud > https://github.com/4383/ <https://github.com/4383/> >

7 months, 1 week

Re: #eventlet-removal - Progress & Update

by Dmitry Tantsur

Hi, On 10/9/24 9:36 AM, Herve Beraud wrote: > Hey there, > > @Arnaud: Mistral is already in our list of identified deliverables: > https://wiki.openstack.org/wiki/Eventlet- > removal#Map_of_the_Impacted_Deliverables <https://wiki.openstack.org/ > wiki/Eventlet-removal#Map_of_the_Impacted_Deliverables>. But thanks for > the heads up. By the way, was this list compiled based on a text search? It lists a few *-specs repositories which are unlikely to be impacted. The mentions of puppet are also suspicious. From the ironic side, I suspect we won't be migrating ironic-inspector and its client as they are deprecated. I haven't discussed it with the team though. Dmitry > > @engineer2024: I'll let the Nova team answer your question. > > Le mar. 8 oct. 2024 à 22:56, Arnaud Morin <arnaud.morin(a)gmail.com > <mailto:arnaud.morin@gmail.com>> a écrit : > > Hey Herve, > > Please add mistral to your list. > I havn't dig into code for this yet, but it's in requirements and it > seems to be used by some of the services. > > Regards, > Arnaud. > > On 04.10.24 - 17:08, Herve Beraud wrote: > > We’re excited to share 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 move forward with this critical initiative. > > > > ## Current Status > > > > We’ve completed the initial analysis phase across more than 120 > OpenStack > > projects. This includes identifying the various patterns where > Eventlet is > > currently in use and evaluating where it can be safely removed or > disabled. > > Here are some highlights: > > > > - Completed Analysis: Projects where Eventlet is used include > (but are not > > limited to): Aodh, Barbican, Nova, Neutron, Tacker, Taskflow, > Trove, Venus, > > Watcher, and Zun. > > > > - Eventlet Optional: Several projects have been identified where > Eventlet > > seems to be optional and can be disabled with minimal impact. For > these > > projects, we will move forward the discussion with teams to try > > deactivating Eventlet in upcoming updates. Once done, projects of > this kind > > would be able to start their migration with more serenity. > > > > - Eventlet Required: Some projects still rely heavily on Eventlet > for core > > functionality. For these, we are going to develop specific > migration plans. > > > > ## Migration Plans in Progress > > > > - oslo.db: Preparing its Asyncio based engine facade; > > - oslo.service: Refactoring plans being discussed to minimize > disruption > > during the migration; > > - glance: Refactoring code to use native thread model rather than > Eventlet > > > > More details can be found here: > > https://review.opendev.org/q/topic:%22eventlet-removal%22 > <https://review.opendev.org/q/topic:%22eventlet-removal%22> > > > > ## Latest Updates > > > > - Community Goal Transition: The ongoing community goal for removing > > Eventlet is now in the process of becoming an official "selected" > goal, > > https://review.opendev.org/c/openstack/governance/+/931254 > <https://review.opendev.org/c/openstack/governance/+/931254>. > > > > - Pattern Identification Completed: We’ve identified key patterns > related > > to Eventlet usage, including its common integration with > monkey_patch(), > > eventlet.Timeout, eventlet.GreenPool, and eventlet.wsgi.server(). > Visit the > > official wiki to get more details > > https://wiki.openstack.org/wiki/Eventlet- > removal#Identifying_Common_Pattern <https://wiki.openstack.org/wiki/ > Eventlet-removal#Identifying_Common_Pattern> > > > > ## Important Dates > > > > - October 21st: cross PTG session. > > - October 23rd: cross PTG session (Q&A session and Open > Discussion session) > > > > ## Call to Action > > > > We need your involvement to accelerate the progress of this > initiative! If > > your project is affected by Eventlet, now is the time to start > planning > > your migration. Teams are encouraged to take immediate steps in > assessing > > how to deactivate Eventlet or to transition to alternative solutions. > > > > We defined key roles and responsibilities. Those will help us to > lower the > > cost of the migration for our community. Teams are invited to > assign them > > now. Being ready as soon as possible will allow you to better take > > advantage of the coming PTG sessions. > > > > Please find more details about these roles and their short terms > tasks: > > https://wiki.openstack.org/wiki/Eventlet- > removal#Roles_and_Responsibilities <https://wiki.openstack.org/wiki/ > Eventlet-removal#Roles_and_Responsibilities> > > > > ## Final Thoughts > > > > This is a significant step forward for improving the stability, > > scalability, and maintainability of our projects. With your continued > > support, we’re confident that this migration will bring substantial > > benefits to the OpenStack community. > > > > If there are any questions or if you need assistance with your > project’s > > transition away from Eventlet, please join the discussion on the > > #eventlet-removal channels (OpenStack irc, RedHat slack, mailing > list). > > > > 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/> > > > > -- > Hervé Beraud > Senior Software Engineer at Red Hat > irc: hberaud > https://github.com/4383/ <https://github.com/4383/> >

1 year, 2 months

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

by Herve Beraud

Hello Chris, It seems to me that Jay already answered your question weeks ago in your previous email. Here is Jay's answer: > oslo.service supports threading now; see > https://docs.openstack.org/oslo.service/latest/user/backend.html <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. Here is the link to his original response https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack… Let us know if you have any additional questions. Le jeu. 4 sept. 2025 à 16:46, Chris Friesen <chris.friesen(a)windriver.com> a écrit : > 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 > > -- Hervé Beraud Principal Software Engineer at Red Hat irc: hberaud https://github.com/4383/

3 months, 4 weeks

#eventlet-removal - Progress & Updates - Flamingo milestone 1

by Herve Beraud

TL;DR: We just passed the milestone 1 of Flamingo and at this point big fishes like Neutron, Nova, Glance, and Mistral demonstrated awesome progress in their migration. Oslo.service's new backend is now usable in real life use cases. Eventlet still suffers from a new version of Python. If you have not yet started your migration yet, then, please consider starting ASAP before the aircraft crash. ## OpenStack Updates Neutron's L3 agent is well on its way to running its WSGI features without using Eventlet and activating the new oslo.service threading backend at runtime. Allowing to decouple a bit more the needs of Eventlet at runtime. Nova scheduler is now able to start in threading mode without requiring any usage of Eventlet at runtime. This was possible by also shifting nova-scheduler to the threading backend of oslo.service. More details are available here https://gibizer.github.io/categories/eventlet/ Activating the new threading backend of oslo.service required devstack adaptation to allow having jobs running this execution mode. https://review.opendev.org/c/openstack/devstack/+/948436. Everybody will be able to benefit from these adaptations. Glance continues its adaptation journey by migrating its functional jobs to reduce its needs of Eventlet and to allow it to run jobs in threading mode. oslo.service's new backend is on the way to be landed soon, and is waiting for additional reviews. https://review.opendev.org/c/openstack/oslo.service/+/945720 ## Eventlet Updates Our CI was failing for almost 2 months, we were able to unlock this failing CI and hence we were able to merge several blocked reviews. Last week Eventlet 0.40.0 was released. This new version provides fixes around OpenSSL 3.5+. The support of Python 3.8 and of PyPy were removed. The Python 3.13 issues are still not solved and require further work. ## Call to Action Flamingo is a crucial series in the realization of global migration of OpenStack. We need your involvement to accelerate the progress of this initiative! If your project is affected by Eventlet, now is the time to start your migration. Teams are invited to read the migration guide available at https://removal.eventlet.org/ and are encouraged to join the #openstack-eventlet-removal IRC channel to get help. You'll benefit quickly from the advantages of running your deliverables without using Eventlet. ## Final Thoughts Postponing the beginning of the migration will put additional pressure related to growing runtime failures of Eventlet. We want to prevent this from happening to you. We are now going straight to milestone 2 meaning that we will soon be in the middle of Flamingo. The migration path is now well cleared by all the previous actions and changes applied into OpenStack. Do not be afraid by the migration and take advantage of the collected experience. Your journey start here https://removal.eventlet.org/ Thanks for reading. -- Hervé Beraud Principal Software Engineer at Red Hat irc: hberaud https://github.com/4383/

7 months, 1 week

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

by Walter Boring

Hello there, I have added a WIP patch for oslo.vmware in gerrit to remove oslo.vmware's reliance on eventlet. Both cinder and nova use oslo.vmware to support vmware as a valid backend. I would not consider oslo.vmware to be experimental as it's been around for ages. The only thing I might need help with is the replacement of eventlet.Timeout usage. Looks like nova still relies on eventlet.timeout as well. Not sure if my WIP is the right way to go, but since oslo.service has an abstraction already in place to replace eventlet, my WIP relies on that abstraction to replace the copied loopingcall classes. Those loopingcall classes that were declared in oslo.vmware have been switched to use the oslo.service abstraction. Walt On Tue, Feb 11, 2025 at 4:59 AM Herve Beraud <hberaud(a)redhat.com> 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 > > 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/ > >

10 months, 2 weeks

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