Jump to: navigation, search

Difference between revisions of "Modernize Openstack Networking Programming Model"

(Medium terms solutions)
 
Line 54: Line 54:
 
* [ ] 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 (https://wiki.openstack.org/wiki/Eventlet-Based-Deliverables-Easily-Migrated)
  
 +
* [ ] Adapt devstack to switch to the new eventlet asyncio hub https://review.opendev.org/c/openstack/devstack/+/914108
  
 +
* [ ] 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==
 
==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