#eventlet-removal - Progress & Update
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/
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 ? On Fri, 4 Oct 2024, 20:38 Herve Beraud, <hberaud@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/
Le ven. 4 oct. 2024 à 17:41, engineer2024 <engineerlinux2024@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@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/
On Wed, 2024-10-09 at 12:01 +0200, Sylvain Bauza wrote:
Le ven. 4 oct. 2024 à 17:41, engineer2024 <engineerlinux2024@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. i dont think we will ever have a "beta" release without eventlet our expection is that we will do a phased removal.
so the iniall goal was to to tackel some of the low hanging furit in dalmation the first part of that was spliting the delivberable in nova that actully need eventlet vs those that dont i.e. the command line clinets were monkey patched but never needed eventlet so those were simple to seprate to remove the monkey patching thats what https://review.opendev.org/c/openstack/nova/+/904424 does the next step is to remove our use of eventlets thread pool and replace it with futureist's version. https://review.opendev.org/c/openstack/nova/+/922497/5 https://review.opendev.org/c/openstack/nova/+/905287/9 https://review.opendev.org/c/openstack/nova/+/917962/8 the third step is to remove the only usage of eventlet in the nova-api wsgi module https://review.opendev.org/c/openstack/nova/+/905284/7 i may or may not have time to work on this in 2025.1 i will likely try to make some progress but i may need to hand this off to someone else or rope in some other to help. if we can compelte what i had orginally scoped in https://blueprints.launchpad.net/nova/+spec/eventlet-removal-part-1 for 2025.1 that woudl be a good first step. next steps would be two fold. first we need to change how spawn core service event loop by using the new backend being added by https://review.opendev.org/c/openstack/oslo-specs/+/927503 second we need to change how we handel rpc requests. when the agent recives an rpc instest of executiong the function on the main thread we need to dispatch that to either a GreenThreadPoolExecutor when we are monkey patched (using eventlet) https://github.com/openstack/futurist/blob/master/futurist/_futures.py#L318 or a ThreadPoolExecutor https://github.com/openstack/futurist/blob/master/futurist/_futures.py#L99 when we are not usign eventlet. that is requried so we can still have concurrent interleaved rpc processing and allow the threaded version to just block waiting on future as needed. that bit i have not figured out exactly where to do that yet. but factoring out the rpc handling to use the executor interface would likely be eventlet-removal-part-2 (2025.2) since that can be done without a dep onthe oslo.service change and then eventlet-removal-part-3 2026.1 woudl be converting to the new oslo.servce backend and any remaining clean up. that is optimistic and a lot of work so it may take longer or we might be able to start some other things earlier. tehre is a lot of good work in https://wiki.openstack.org/wiki/Eventlet-removal#Migration_Plan also. nova at present is not planning to use asynio but that does nto mean we never will we just dont have a high enough concurrence requireemtn to need it so trhead pools shoud be sufficient once we are using them there is no reaosn we coudl not have an AsyncioPoolExecutor using awaitlet or explore using asyncio more directly to your debugger point any servie that is not monkey patched will gain the ablity to just run in a debugger normally i.e. once we get rid of using it in the api wsgi module you should be able to just debug it but keep in mind that nova is a distributed system os if you set a breakpoint you will very likly cause request to time out. debuging a distribute system is not the same as debuging a application running on a single host and never will be. that is not a goal of this work its just a side benifit.
-Sylvain
On Fri, 4 Oct 2024, 20:38 Herve Beraud, <hberaud@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/
Hello all: This is a quick update of the status of Neutron and stadium projects in the eventlet deprecation. We have created a topic for next week PTG [1]. During the PTG we'll discuss the deprecation strategy. In order to facilitate the analysis, I've created [2], that is a collaborative document with the relevant code findings related to eventlet. A month ago I sent an update [3] with a list of patches merged, most of them related to issues in the Neutron API eventlet to WSGI migration. Now we have the ML2/OVS jobs migrated and the ML2/OVN are proposed for neutron-tempest-plugin and merged for Neutron: * https://review.opendev.org/c/openstack/neutron/+/923711 * https://review.opendev.org/c/openstack/neutron-tempest-plugin/+/923730 * https://review.opendev.org/c/openstack/neutron/+/924317 * https://review.opendev.org/c/openstack/neutron-tempest-plugin/+/930743 We have also proposed some trivial (but necessary) patches to remove some eventlet methods in the code: * https://review.opendev.org/c/openstack/neutron/+/931249 * https://review.opendev.org/c/openstack/neutron/+/931251 The next steps will be defined in the PTG and made public here and in the PTG summary. Regards. [1]https://etherpad.opendev.org/p/oct2024-ptg-neutron [2]https://etherpad.opendev.org/p/neutron-eventlet-deprecation [3] https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack.... On Wed, Oct 9, 2024 at 1:38 PM <smooney@redhat.com> wrote:
Le ven. 4 oct. 2024 à 17:41, engineer2024 <engineerlinux2024@gmail.com> a écrit :
That's encouraging news. I hope the new alternative would support a
On Wed, 2024-10-09 at 12:01 +0200, Sylvain Bauza wrote: 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. i dont think we will ever have a "beta" release without eventlet our expection is that we will do a phased removal.
so the iniall goal was to to tackel some of the low hanging furit in dalmation the first part of that was spliting the delivberable in nova that actully need eventlet vs those that dont
i.e. the command line clinets were monkey patched but never needed eventlet so those were simple to seprate to remove the monkey patching thats what https://review.opendev.org/c/openstack/nova/+/904424 does
the next step is to remove our use of eventlets thread pool and replace it with futureist's version. https://review.opendev.org/c/openstack/nova/+/922497/5 https://review.opendev.org/c/openstack/nova/+/905287/9 https://review.opendev.org/c/openstack/nova/+/917962/8
the third step is to remove the only usage of eventlet in the nova-api wsgi module
https://review.opendev.org/c/openstack/nova/+/905284/7
i may or may not have time to work on this in 2025.1
i will likely try to make some progress but i may need to hand this off to someone else or rope in some other to help. if we can compelte what i had orginally scoped in https://blueprints.launchpad.net/nova/+spec/eventlet-removal-part-1 for 2025.1 that woudl be a good first step.
next steps would be two fold. first we need to change how spawn core service event loop by using the new backend being added by https://review.opendev.org/c/openstack/oslo-specs/+/927503
second we need to change how we handel rpc requests. when the agent recives an rpc instest of executiong the function on the main thread we need to dispatch that to either a GreenThreadPoolExecutor when we are monkey patched (using eventlet) https://github.com/openstack/futurist/blob/master/futurist/_futures.py#L318 or a ThreadPoolExecutor https://github.com/openstack/futurist/blob/master/futurist/_futures.py#L99 when we are not usign eventlet.
that is requried so we can still have concurrent interleaved rpc processing and allow the threaded version to just block waiting on future as needed.
that bit i have not figured out exactly where to do that yet. but factoring out the rpc handling to use the executor interface would likely be eventlet-removal-part-2 (2025.2) since that can be done without a dep onthe oslo.service change and then
eventlet-removal-part-3 2026.1 woudl be converting to the new oslo.servce backend and any remaining clean up.
that is optimistic and a lot of work so it may take longer or we might be able to start some other things earlier.
tehre is a lot of good work in https://wiki.openstack.org/wiki/Eventlet-removal#Migration_Plan also.
nova at present is not planning to use asynio but that does nto mean we never will we just dont have a high enough concurrence requireemtn to need it so trhead pools shoud be sufficient
once we are using them there is no reaosn we coudl not have an AsyncioPoolExecutor using awaitlet or explore using asyncio more directly
to your debugger point any servie that is not monkey patched will gain the ablity to just run in a debugger normally i.e. once we get rid of using it in the api wsgi module you should be able to just debug it but keep in mind that nova is a distributed system os if you set a breakpoint you will very likly cause request to time out. debuging a distribute system is not the same as debuging a application running on a single host and never will be.
that is not a goal of this work its just a side benifit.
-Sylvain
On Fri, 4 Oct 2024, 20:38 Herve Beraud, <hberaud@redhat.com> wrote:
We’re excited to share the latest updates on our ongoing efforts to
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
projects, we will move forward the discussion with teams to try deactivating Eventlet in upcoming updates. Once done, projects of
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
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
transition away from Eventlet, please join the discussion on the #eventlet-removal channels (OpenStack irc, RedHat slack, mailing
phase these this kind planning project’s list).
Thank you for your dedication and hard work!
-- Hervé Beraud Senior Software Engineer at Red Hat irc: hberaud https://github.com/4383/
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/
Hey there, @Arnaud: Mistral is already in our list of identified deliverables: https://wiki.openstack.org/wiki/Eventlet-removal#Map_of_the_Impacted_Deliver.... 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@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.
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
On 04.10.24 - 17:08, Herve Beraud wrote: 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!
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
If 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/
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@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/>
Le lun. 14 oct. 2024 à 13:05, Dmitry Tantsur <dtantsur@protonmail.com> a écrit :
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.
Indeed, this list was created by using beagle ( https://beagle-hound.readthedocs.io/en/latest/user/index.html) so it includes all kinds of occurence, even specs repository. I think we can ignore this kind of occurence, but I think they can also be useful to help us to identify some previous architectural decisions. To reduce the noise, I'll do another round of filtering to keep only legit occurrences, and I'll put the specs "results" into a separated section. Do not hesitate to use Beagle for our deliverables. Beagle allows you to ignore files, and allows you to use matching patterns.
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@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/>
-- Hervé Beraud Senior Software Engineer at Red Hat irc: hberaud https://github.com/4383/
participants (7)
-
Arnaud Morin
-
Dmitry Tantsur
-
engineer2024
-
Herve Beraud
-
Rodolfo Alonso Hernandez
-
smooney＠redhat.com
-
Sylvain Bauza