Last week was the OpenStack PTG. The Eventlet removal initiative ran two PTG sessions. The first session [1] was a presentation of the initiative, where the second session [2] was a technical open discussion.

Please find out below the main key points and the proposed answers.

## Key Points

The first key point made during these PTG sessions is that without consistency in our choices and decisions we will create more complexity than anything else. It is crucial to avoid having multiple ways to start services across different projects. A unified approach will simplify maintenance and enhance user experience.

Leading us to the following questions:
- how to remove the WSGI features provided by Eventlet and how to move to another HTTP server (WSGI/ASGI);
- how to manage tasks.

The WSGI/HTTP server discussion just come in time with the proposal made by Stephen Finucane to Deprecate/remove non-uWSGI deployment mechanisms from Devstack:
https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack.org/message/RQAD4V7LCBJOHIGP2GSBWJSMKGGRVD5A/

We think that this topic overlaps with the WSGI aspects of Eventlet removal, for this reason, with the aim to answer these questions we propose to create specialized working groups (see the section below). We also made comparisons between available alternatives, here is an example with the SGI question https://wiki.openstack.org/wiki/SGI-servers-comparison. Find out all our comparisons in the official wiki page:
https://wiki.openstack.org/wiki/Eventlet-removal#The_HTTP_SGI_Working_Group

## Specialized working groups

The main role of these working groups is to avoid having multiple ways to manage things. Groups would be responsible for producing a unified approach that will simplify maintenance and enhance user experience.

Our discussions have brought out 3 specialized working groups:
- The HTTP SGI Working Group
- The Tasks/Process Working Group
- The Architecture, Interoperability and Technical Standardization Working Group

If you are interested in one or many of these specialized working groups, then, please raise your hand and join the discussions. Please also take a look to the official page:
https://wiki.openstack.org/wiki/Eventlet-removal#Specialized_Working_Groups_2

## Latest Updates

- Glance took full advantage of the PTG discussion. They got an overview of their WSGI migration options and they gain a better understanding of their current situation (https://etherpad.opendev.org/p/oct2024-ptg-glance#L277), and the Glance team were able to set up a migration plan:
https://etherpad.opendev.org/p/oct2024-ptg-glance#L340

- Ironic Python Agent (IPA), is also experimenting about their Eventlet removal, their works is strongly related to the WSGI feature replacement:
 https://review.opendev.org/c/openstack/ironic-python-agent/+/924634

- The threading executor of oslo.messaging could shorten our migration path concerning the RPC aspects. For this reason we proposed to start the deprecation of the Eventlet executor within oslo.messaging. https://review.opendev.org/c/openstack/oslo.messaging/+/933399

- Another topic that arose during the PTG is how to manage timeouts. Some proposal have been made, they propose to rely on SQLAlchemy or Ceph to handle timeout management:
https://etherpad.opendev.org/p/oct2024-ptg-eventlet-removal#L103
https://etherpad.opendev.org/p/oct2024-ptg-os-tc#L298

## Important Dates

Nov. 5th is the first IRC meeting on #openstack-eventlet-removal, do not hesitate to join us. We will cover all the topics addressed in this mailing thread.

## SLURP vs non-SLURP

The PTG sessions came with timeline and cadence discussions. For this reason we made some proposal about workload regulation:
https://wiki.openstack.org/wiki/Eventlet-removal#Workload_regulation_2

In substance we propose to base our cadence on SLURP and non-SLURP releases. Epoxy is a SLURP release, for this reason we should not expect breaking changes happening during this series, however, SLURP series are good opportunities to deprecate things, remove useless workaround, and start small clean up in preparation of wider changes.

## Final Thoughts

We strongly encourage a collaborative  selection of our candidate(s) for HTTP server replacement .This selection will dictate how we deal with server gateway interfaces for the coming decade, so we should focus our coming discussion on this specification, for this reason we invite you to join the specialized working groups.

Thanks to all the people who joined the various discussions.
Thank you for your dedication and hard work!

[1] https://etherpad.opendev.org/p/oct2024-ptg-os-tc#L195
[2] https://etherpad.opendev.org/p/oct2024-ptg-eventlet-removal

--
Hervé Beraud
Senior Software Engineer at Red Hat
irc: hberaud