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

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

by Takashi Kajinami

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

5 months, 3 weeks

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

by Douglas Viroel

Hi hberaud o/ Thanks for the updates. The Watcher team also started investigating eventlet usage in the code and proposed some initial actions. We started to follow up this effort in our weekly meeting too. Our etherpad is the following: https://etherpad.opendev.org/p/watcher-eventlet-removal BR, On Tue, May 20, 2025 at 3:51 PM Herve Beraud <hberaud(a)redhat.com> wrote: > > > Le mar. 20 mai 2025 à 18:47, Dmitry Tantsur <dtantsur(a)protonmail.com> a > écrit : > >> Hi! >> >> Thank you for the update, here is the etherpad I created for Ironic: >> https://etherpad.opendev.org/p/ironic-eventlet-removal >> >> > Thank you Dimitry, that looks pretty amazing, kudos! Let me add it to our > collection of efforts. > > >> 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/> >> > >> >> >> > > -- > Hervé Beraud > Principal Software Engineer at Red Hat > irc: hberaud > https://github.com/4383/ > > -- Douglas Viroel - dviroel

2 months, 3 weeks

Re: [eventlet-removal]When to drop eventlet support

by thomas＠goirand.fr

On Jun 13, 2025 14:09, Balazs Gibizer <gibi(a)redhat.com> wrote: > What do you think? > > Cheers > gibi Hi, Thanks for sharing your thoughts. Mostly: that as the Debian package maintainer of OpenStack, the current situation is VERY uncomfortable. :( It all depends on if we can get Eventlet fixed for Python 3.13. Worst case, if mobody finds a way to fix https://github.com/eventlet/eventlet/issues/1032 then from my perspecrive (ie: as the Debian package maintainer), Nova MUST be fixed for 2026.1. Indeed, otherwise Debian 12 will be EOL too early, putting Debian OpenStack operators at risk of unpatch security bugs (I do not want to rely too much on the Debian LTS effort). Do you think that's possible? If not, then some more effort should be spent on maintaining Eventlet and make it works on Python 3.13 (and 3.14). Cheers, Thomas Goirand (zigo)

2 months

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

by Herve Beraud

Hey Walter, Thank you for your initiative, that's the right way to go. I added myself into the reviewers of your patch. Concerning timeout usages, here is an example of one option Mistral used to drop them https://review.opendev.org/c/openstack/mistral/+/942058 Let us know if you want us to setup a deeper discussion about tiimeout during our next meeting https://wiki.openstack.org/wiki/Eventlet-removal#Recurring_Events Le mar. 18 févr. 2025 à 15:58, Walter Boring <waboring(a)hemna.com> a écrit : > 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/ >> >> -- Hervé Beraud Senior Software Engineer at Red Hat irc: hberaud https://github.com/4383/

5 months, 2 weeks

Re: #eventlet-removal - Progress & Update

by Herve Beraud

Hey there, @Arnaud: Mistral is already in our list of identified deliverables: https://wiki.openstack.org/wiki/Eventlet-removal#Map_of_the_Impacted_Delive…. But thanks for the heads up. @engineer2024: I'll let the Nova team answer your question. Le mar. 8 oct. 2024 à 22:56, Arnaud Morin <arnaud.morin(a)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 > > > > ## 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/ > > -- Hervé Beraud Senior Software Engineer at Red Hat irc: hberaud https://github.com/4383/

10 months

Re: [eventlet-removal]When to drop eventlet support

by thomas＠goirand.fr

On Jun 13, 2025 20:52, Jay Faulkner <jay(a)gr-oss.io> wrote: > > 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 Right. Plus I don't get why operators get to choose what class of bugs they may experience, and how they will know beter than contributors. Cheers, Thomas Goirand (zigo)

2 months

[masakari] failures with new version of Eventlet

by Herve Beraud

Hey Masakari maintainers, Masakari is failing with new the version of Eventlet https://review.opendev.org/c/openstack/requirements/+/933257 This job failure indicates that Masakari will surely stop working correctly once this version bump will be merged, and we need that requirements bump to support newer versions of Python in OpenStack, so... Masakari is a non-voting job, so even if this job is failing, the requirement bump will proceed, but that would be better if every project is compatible and ready to go. If you need help do not hesitate to: - join us on #openstack-eventlet-removal; - join us at our next meeting (Dec 17) https://wiki.openstack.org/wiki/Eventlet-removal#Recurring_Events. Thanks for your hard work. -- Hervé Beraud Senior Software Engineer at Red Hat irc: hberaud https://github.com/4383/

8 months, 1 week

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

by Herve Beraud

Thanks Douglas. I also added your etherpad into the teams efforts tracker https://wiki.openstack.org/wiki/Eventlet-removal#Teams_efforts Le mar. 20 mai 2025 à 21:02, Douglas Viroel <viroel(a)gmail.com> a écrit : > Hi hberaud o/ > > Thanks for the updates. > The Watcher team also started investigating eventlet usage in the code and > proposed some initial actions. > We started to follow up this effort in our weekly meeting too. > Our etherpad is the following: > https://etherpad.opendev.org/p/watcher-eventlet-removal > > BR, > > On Tue, May 20, 2025 at 3:51 PM Herve Beraud <hberaud(a)redhat.com> wrote: > >> >> >> Le mar. 20 mai 2025 à 18:47, Dmitry Tantsur <dtantsur(a)protonmail.com> a >> écrit : >> >>> Hi! >>> >>> Thank you for the update, here is the etherpad I created for Ironic: >>> https://etherpad.opendev.org/p/ironic-eventlet-removal >>> >>> >> Thank you Dimitry, that looks pretty amazing, kudos! Let me add it to our >> collection of efforts. >> >> >>> 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/> >>> > >>> >>> >>> >> >> -- >> Hervé Beraud >> Principal Software Engineer at Red Hat >> irc: hberaud >> https://github.com/4383/ >> >> > > -- > Douglas Viroel - dviroel > -- Hervé Beraud Principal Software Engineer at Red Hat irc: hberaud https://github.com/4383/

2 months, 3 weeks

Re: #eventlet-removal - Progress & Update

by Sylvain Bauza

Le ven. 4 oct. 2024 à 17:41, engineer2024 <engineerlinux2024(a)gmail.com> a écrit : > That's encouraging news. I hope the new alternative would support a python > debugger like pdb. This will help the new users to understand the > flow better. So when can we expect initial release atleast beta of eventlet > free nova components ? > > That's an excellent question that I don't have an answer. We started to work on it on Dalmatian but for the moment, I don't know whether the owner could continue to work on it on Epoxy or if someone else would do it. -Sylvain On Fri, 4 Oct 2024, 20:38 Herve Beraud, <hberaud(a)redhat.com> 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 >> >> ## 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/ >> >>

10 months

#eventlet-removal - Announcing the New Threading Backend of oslo.service

by Herve Beraud

I'm happy to announce the new version of oslo.service is out! [1] This new version came out with the new Threading backend [2]. OpenStack Upper constraints are on the way to be upgraded to this new version [3]. You can start using the new threading backend by following the steps below: ``` import oslo_service.backend as service service.init_backend(service.BackendType.THREADING) ``` Ideally this backend selection should be made in your patcher module. Almost all OpenStack services own a household patcher. Neutron and Nova already demonstrated a successful adoption of this new backend on Nova scheduler and Neutron L3 agent: - https://review.opendev.org/c/openstack/neutron/+/938404 - https://review.opendev.org/c/openstack/nova/+/948450/17 Devstack is on the way to be adapted to allow you to set up `SYSTEMD_ENV_VARS`. [4] This will allow passing environment variables from zuul job definitions to systemd service files via the local conf. During the Eventlet removal effort this will allow teams to have separate jobs testing the same service in different concurrency modes. The first use case of this is to implement scenarios like passing variable `OS_NOVA_DISABLE_EVENTLET_PATCHING=true` to nova services that already supports running in native threading mode instead of with Eventlet. To get a more concrete integration example, you can take inspiration from Nova patches [5][6] to see how to implement your backend switch on your deliverables. A comprehensive guide is currently under creation. [7] Next steps will be to address a couple of remaining comments, to introduce functional tests, and to democratize the usages of this new backend. Thank you to Daniel for his hard work and all his efforts on this topic. Also I wanted to specially thank Gibi and Rodolfo for their close collaborations on this new backend implementation. Please join me to warmfully thank them. Our mission is to equip the community with everything it needs to leave Eventlet behind. This backend is only a tiny piece of this giant puzzle. Your turn to place your piece: https://removal.eventlet.org Cheers, [1] https://review.opendev.org/c/openstack/releases/+/950646 [2] https://review.opendev.org/c/openstack/oslo.service/+/945720 [3] https://review.opendev.org/c/openstack/requirements/+/950653 [4] https://review.opendev.org/c/openstack/devstack/+/948436 [5] https://review.opendev.org/c/openstack/nova/+/948311 [6] https://review.opendev.org/c/openstack/nova/+/948450 [7] https://review.opendev.org/c/openstack/oslo.service/+/940664 -- Hervé Beraud Principal Software Engineer at Red Hat irc: hberaud https://github.com/4383/

2 months, 3 weeks

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