On Wed, 2023-11-22 at 14:37 +0100, Thomas Goirand wrote:
On 11/10/23 15:31, Julia Kreger wrote:
I've known for a while that eventlet had some issues, but I wasn't aware of just how much was or was not going on. I guess it all seemed to be moderately under control and acceptable until a bright light was shined on it. To me, Eventlet's state doesn't seem very acceptable for the long term health of OpenStack as a project, and all consumers of OpenStack and OpenStack component technologies. Thanks JayF for raising visibility and getting this discussion started.
I think regardless of path, we will likely need to take a phased approach, and see if there is any way we can plan out a "path".
Some things I think we should be thinking about:
* What is our short term path? What are the steps we can execute upon quickly without too much interruption to projects? * Is a fork to live for a few cycles acceptable to us, or not? * Are there intermediate steps we can take as we plan and begin executing on a long term plan? * Are there "smaller", more isolated, places we can start and move forward to a desired end state faster than others? * Are we okay with an intermediate end state? What is "good enough" in this case.
Hi Julia,
For me, one obvious path is to get away from eventlet in the long run (thanks Sean, for suggesting gevent...). I'm fully aware that getting away from eventlet represent a lot of work. But at the same time, monkey patching, and accessing through private function of the Python standard lib is really horrible... and if there's *ONE* thing that I could with the project to work on, that'd be it. We've known this for years (since the beginning of OpenStack, in fact), and the technical dept is just accumulating. If this is kept unaddressed, it will continue to bite hard on each Python interpreter release. well yes and no characterizing eventlet as technial debt when there has never be a agreement to stop using it or change our treading model is unfair. It is the selected technology today. openstack didn't start with eventlet we actually started with twisted and moved to eventlet for numerous reasons very early on. one of those was to avoid explicit concurrency in our code base. at the time it was consdier less error prone to use implicit concurrency and a framework that supported cooperative user land greenthreadign then explicit concurrency. im not going to comment on if that statement was correct but it was one fo the motivating factors.
if we as a community want to actully move away from eventlet to somethign else this is something we will need to do over the course of multiple release including support supporting both like across one slurp release. This would have to be a desicsion driven across project and via a tc resolution or community goal like secure rbac. all of the replacement other then gevnt requrie chaing the threading/concurrency model of all services that currently use eventlet form implicit concurrency to explicit concurrency https://docs.openstack.org/nova/latest/reference/threading.html if we were to try and remove eventlet today one of the first thing we would need to do is extend oslo.service https://github.com/openstack/oslo.service so that it can be used without eventlet. in parallel to that we would have to convert any explict usage or eventlet in all the project and libs to either go via an absrction like futureist or use std lib fucnton or a diffenrt framework. usiging stdlib modules is what i started doing in https://review.opendev.org/q/topic:%22gevnet%22 but its very non trivial and nova is one of the project that uses eventlet with out hevially depending on its internals swift is very very tightly coupled to eventlet i belive and i suspect would be one of the hardest projects to rewirte into a non eventlet mode. i generally would like to see us move to asyncio (possible with gevnet as a bridge) but it hard to justify investing the time to do that unless there is a agreement in the comunity that this will actully be done in all relevent projects and we can show a beifit to this to our users. i would say having openstack actully work on 3.12/3.13 is a definitive benift to user but if you have a downstream product based on py39 it hard to justify to PMs why this must be done now and not in n years time when we are trying to build a product on 3.12. its short sighted but its a reality that rewrting a mature project like openstack to use a fundementally different execution model is unpalitable to those who want stablity. i can try to raise this internally again but unless its recognised at a TC/compunity level as a probelem that must be solved its hard to argue agaisn the status quo
But in the mean while, Python 3.12 support *MUST* be added to Eventlet ASAP. The transition to 3.12 in Debian Unstable (and soonish Ubuntu) has already started, and I'm getting bugs report related to Eventlet already (which I cannot fix until there's a build of greenlet with 3.12 support...).
Cheers,
Thomas Goirand (zigo)