#eventle-removal - Progress & Updates Epoxy Milestones 2-3
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/
On 2/11/25 10:58, Herve Beraud wrote:
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?
The main issue I see with Heat, is that it's the only way to do auto-scalling. Otherwise, we would push all of our users to use opentofu exclusively. Cheers, Thomas Goirand (zigo)
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/>
Le lun. 17 févr. 2025 à 14:19, Takashi Kajinami <kajinamit@oss.nttdata.com> a écrit :
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.
You're right Takashi, I should have contacted you first. I apologize. My goal with that thread was simply to ensure that we are able to conduct the eventlet migration safely and not to dictate an architecture or a decision. I simply wanted to ensure that this migration effort wouldn't rely on the shoulders of only one person and ensure that we assign the needed resources in time. but I admit that I did it clumsily. and again I apologize for that. In the case some vendors would already have some tracks to replace heat by an alternative, I wanted to weigh the pros and cons of a potential global replacement rather than an eventlet costly migration. But, now that the nail is hammered in, the sooner the discussion, the better resource allocation, the smoother the migration. In addition to that, when I wrote my original sentence, especially the part about "more modern ways to orchestrate OpenStack" I was only supposing that the recent OpenShift move (RHOSO) by Red Hat would open the doors of an alternative orchestration of OpenStack through OpenShift mechanisms. But I had a RedHat centric point of view concerning this point, and I didn't consider the feasibility and all the vendors and the community sides.This is an abusive generalization on my part. You should also notice that I speak on my own concerning this point, there is yet no official RedHat downstream discussions/positions about removing Heat either. To finish, given all the various discussions I recently had following this thread, it seems, at first glance, that the migration is feasible and not so hard, so that's good news. I see that you recently proposed a patch to start, in some aspects, the removal of eventlet from heat https://review.opendev.org/c/openstack/heat/+/932925, that's a good start. Thank you Takashi for all your hard work on Heat and in OpenStack in general and sorry again for the misunderstanding generated by this thread.
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/>
-- Hervé Beraud Senior Software Engineer at Red Hat irc: hberaud https://github.com/4383/
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@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/
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@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@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/
On 24/02/2025 13:45, Herve Beraud wrote:
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@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.
Nova will not be deprecating the use of eventlet until 2026.1 nova is not capable of rungin with out eventlet in 2025.1 and we will not do the deprecation until that is possible. we may or may not be able to run without eventlet in 2025.2 but our initall target to support using the non eventlet backend of oslo.servce ectra will be 2026.1 the earlist we might remove supprot for eventlet is 2026.2 currently we do not have poeple working on this. looping call is part of the top level oslo.service api and will be ported to using the impelmation from futurist in the non eventlet backend so as long oslo.vmware is usign the oslo.servie veriosn that should be transparent. https://github.com/openstack/oslo.service/blob/master/oslo_service/loopingca... the eventlet.Timeout usage however ves is harder to replace. i think it only used here https://github.com/openstack/oslo.vmware/blob/face67836e6d9c7eb63cb52e8120b8... that likely can be delegated to a background io thread pool and a future can be return which can be waited on. ideally the time out would be proagated to the underlying soap/rest client that is doign the upload so the connection can be closed if the timeout is exceeded butim not famialr with exactly how that works in this libary. in general lib like oslo.vmware should avoid using eventlet or looping call directly but oslo.vmware has a few release to transition to the new model. this does nto need to be doen before Epoxy milestone 3
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@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/
participants (5)
-
Herve Beraud
-
Sean Mooney
-
Takashi Kajinami
-
Thomas Goirand
-
Walter Boring