Hey team, Just my two cents in this topic. As an operator, I am eager to get rid of eventlet everywhere. The current situation is painful, very hard to debug on daily basis. There is no day without hearing from the team: oh, you know, maybe it's an eventlet bug :) Cheers, Arnaud On 16.06.25 - 11:11, Balazs Gibizer wrote:
On Sat, Jun 14, 2025 at 1:24 AM <thomas@goirand.fr> wrote:
On Jun 13, 2025 20:52, Jay Faulkner <jay@gr-oss.io> wrote:
I'm confused a bit -- the implementation details of our threading modules are not a public API that we owe deprecation periods for. Why are we treating it as such?
-JayF
Right. Plus I don't get why operators get to choose what class of bugs they may experience, and how they will know beter than contributors.
The new concurrency model in nova (native threading) needs different performance tuning than the previous (eventlet). The cost of having 1000 eventlets is negligible but having 1000 threads to replace that will blow up the memory usage of the service. Operators expressed that having such tuning effort happening during upgrade without a temporary way back to the old model is scary. And honestly I agree.
Similarly we expect nasty bugs in the new model as it is a significant architectural change. So having no way to go back to a known good state temporarily while the bug is fixed or worked around is scarry.
Third, if we want to keep green CI while we are transforming nova services to the new model without keeping a big feature branch then we need to be able to land code that passes CI while things are half transformed. The only way we can do that is if we support both concurrency modes in parallel for a while.
Cheers, gibi
Cheers,
Thomas Goirand (zigo)