Jump to: navigation, search

Difference between revisions of "Modernize Openstack Networking Programming Model"

(Medium terms solutions)
 
(4 intermediate revisions by the same user not shown)
Line 1: Line 1:
 +
==Description==
 +
 +
This document aim to track the global advancement of community goal related to the Modernization of the Openstack Networking Programming Model
 +
More details about this goal are available at https://review.opendev.org/c/openstack/governance/+/902585
 +
 +
==Authors==
 +
 +
* Hervé Beraud (hberaud)
 +
 
==Short terms solutions==
 
==Short terms solutions==
  
Line 5: Line 14:
 
[ ] = not yet done
 
[ ] = not yet done
  
- [x] Open a discussion with current eventlet maintainers
+
* [x] Open a discussion with current eventlet maintainers
  
- [ ] (optional) Propose to migrate the official repository into the Openstack organisation
+
* [ ] (optional) Propose to migrate the official repository into the Openstack organisation
  
- [ ] (optional) Start engaging a forking process of eventlet
+
* [ ] start drafting various announcements of the milestones 1, 2, 3 (the new release of eventlet, the creation of aiohub, the complete migration of oslo libs, etc), to try to define thresholds and acceptable and non acceptable things with these milestones. By example, start drafting the announcement of the new fixed release of eventlet with things that we would desire inside. Drafting these announcements early in the process would allow us to see if we really reached our milestones once the time comes.
  
- [ ] (optional) Adapt testing and project structure to your tooling
+
* [ ] (optional) Start engaging a forking process of eventlet
  
- [ ] (optional) Openstack deliverables that rely on it would have to update their requirements to pull the new fork instead of the original version
+
* [ ] (optional) Adapt testing and project structure to your tooling
  
- [ ] (optional) Socialize the move or the fork of eventlet
+
* [ ] (optional) Openstack deliverables that rely on eventlet would have to update their requirements to pull the new fork instead of the original version
  
- [ ] (optional) Cherry pick the existing CI fix into the new repository of eventlet into the Openstack organisation
+
* [ ] (optional) Socialize the move or the fork of eventlet
  
- [ ] Merge the CI patches.
+
* [ ] (optional) Cherry pick the existing CI fix into the new repository of eventlet into the Openstack organisation
  
- [ ] (optional) Cherry pick the existing Python 3.12 fix into the new repository of eventlet into the Openstack organisation
+
* [ ] Merge the CI patches.
  
- [ ] Merge the fix for introduce the support of Python 3.12
+
* [ ] (optional) Cherry pick the existing Python 3.12 fix into the new repository of eventlet into the Openstack organisation
  
- [ ] Release the latest changes by creating a new version
+
* [ ] Merge the fix for introduce the support of Python 3.12
  
- [ ] Upgrade the Openstack requirements to match this new version
+
* [ ] Release the latest changes by creating a new version
  
- [ ] Validate that the main issues are now fixed
+
* [ ] Upgrade the Openstack requirements to match this new version
  
- [ ] Announce the current state of the art after the previous steps are done
+
* [ ] Validate that the main issues are now fixed
  
- [ ] (optional) Decide with the TC to postpone the support of Python 3.12 within the next series ("D") if the validation failed and if we are to close from the deadline. Socialize that point to the community. This is a possible way out that we must still avoid at all costs.
+
* [ ] Announce the current state of the art after the previous steps are done
  
- [ ] (optional) If we previously postponed the support of Python 3.12 due to validation issue, see what happens and try to fix it during "D".
+
* [ ] (optional) Decide with the TC to postpone the support of Python 3.12 within the next series ("D") if the validation failed and if we are to close from the deadline. Socialize that point to the community. This is a possible way out that we must still avoid at all costs.
 +
 
 +
* [ ] (optional) If we previously postponed the support of Python 3.12 due to validation issue, see what happens and try to fix it during "D".
  
 
==Medium terms solutions==
 
==Medium terms solutions==
  
===Design specs of oslo.aiohub===
+
* [ ] Design specs of oslo.aiohub (https://wiki.openstack.org/wiki/Aiohub-Discussion)
 
 
====Description====
 
  
====Specs====
+
* [ ] identifying the low hanging fruits - deliverables that can be easily migrated (https://wiki.openstack.org/wiki/Eventlet-Based-Deliverables-Easily-Migrated)
  
===identifying the low hanging fruits - deliverables that can be easily migrated===
+
* [ ] Adapt devstack to switch to the new eventlet asyncio hub https://review.opendev.org/c/openstack/devstack/+/914108
  
====Ironic-Python-Agent====
+
* [ ] Performance evaluation. Start discussion with operators partners to see if they can switch one of their preprod environment to realize a realistic performance evaluation (comparison  between the current hub in use (epolls) and the future hub to use (asyncio)
The Ironic-Python-Agent project is a good candidate as a pilot for a migration. It uses and relies on eventlet heavily, but has limited inter-openstack dependencies and co-installed dependencies. In general, the Ironic community is onboard to having IPA be a pilot project for this if it's useful (realistically; it may be too simple -- IPA may be an easy enough case just to completely rip eventlet out of without a migration).
 
  
 
==Long terms solutions==
 
==Long terms solutions==

Latest revision as of 16:51, 25 March 2024

Description

This document aim to track the global advancement of community goal related to the Modernization of the Openstack Networking Programming Model More details about this goal are available at https://review.opendev.org/c/openstack/governance/+/902585

Authors

  • Hervé Beraud (hberaud)

Short terms solutions

Legend: [x] = done [ ] = not yet done

  • [x] Open a discussion with current eventlet maintainers
  • [ ] (optional) Propose to migrate the official repository into the Openstack organisation
  • [ ] start drafting various announcements of the milestones 1, 2, 3 (the new release of eventlet, the creation of aiohub, the complete migration of oslo libs, etc), to try to define thresholds and acceptable and non acceptable things with these milestones. By example, start drafting the announcement of the new fixed release of eventlet with things that we would desire inside. Drafting these announcements early in the process would allow us to see if we really reached our milestones once the time comes.
  • [ ] (optional) Start engaging a forking process of eventlet
  • [ ] (optional) Adapt testing and project structure to your tooling
  • [ ] (optional) Openstack deliverables that rely on eventlet would have to update their requirements to pull the new fork instead of the original version
  • [ ] (optional) Socialize the move or the fork of eventlet
  • [ ] (optional) Cherry pick the existing CI fix into the new repository of eventlet into the Openstack organisation
  • [ ] Merge the CI patches.
  • [ ] (optional) Cherry pick the existing Python 3.12 fix into the new repository of eventlet into the Openstack organisation
  • [ ] Merge the fix for introduce the support of Python 3.12
  • [ ] Release the latest changes by creating a new version
  • [ ] Upgrade the Openstack requirements to match this new version
  • [ ] Validate that the main issues are now fixed
  • [ ] Announce the current state of the art after the previous steps are done
  • [ ] (optional) Decide with the TC to postpone the support of Python 3.12 within the next series ("D") if the validation failed and if we are to close from the deadline. Socialize that point to the community. This is a possible way out that we must still avoid at all costs.
  • [ ] (optional) If we previously postponed the support of Python 3.12 due to validation issue, see what happens and try to fix it during "D".

Medium terms solutions

  • [ ] Performance evaluation. Start discussion with operators partners to see if they can switch one of their preprod environment to realize a realistic performance evaluation (comparison between the current hub in use (epolls) and the future hub to use (asyncio)

Long terms solutions