Search results for "#eventlet-removal" - openstack-discuss

Re: [eventlet-removal]When to drop eventlet support

by Sylvain Bauza

(replying to the top of the thread for better visibility) Based on the discussions that occurred on the thread coming from the concern that Gibi raised, I proposed a governance patch for modifying the completion dates of the TC goal https://review.opendev.org/c/openstack/governance/+/952903/ Please comment heavily on that change proposal. Thanks, -Sylvain Le ven. 13 juin 2025 à 14:09, Balazs Gibizer <gibi(a)redhat.com> a écrit : > Hi Stackers! > > I would like to sync about the planned timeline of dropping eventlet > support from OpenStack / Oslo. > > Nova definitely needs at least the full 2026.1 cycle to have a chance > to transform the nova-compute service. But this plan already feels > stretched based on the progress in the current cycle. So being > conservative means we need the 2026.2 cycle as a buffer. > > Nova would like to keep a release where we support both eventlet and > threading in parallel. So that operators can do the switching from > eventlet to threading outside of the upgrade procedure. (This was an > explicit request from them during the PTG). So 2026.2 could be that > version where nova fully supports both concurrency mode, while > eventlet can be marked deprecated. Then the 2027.1 release could be > the first release dropping eventlet. > > However we need to align with the SLURP upgrade as well. 2026.1 is a > SLURP. But in that release Nova might not be ready to have all > services running in threading mode. So the 2026.1 - 2027.1 SLURP > upgrade would force the operators to change the concurrency mode > during the upgrade itself. > > I see two ways forward: > * A) We say that operators who want to do the concurrency mode change > outside of an upgrade could not skip the 2026.2 release, i.e. they > cannot do SLURP directly from 2026.1. to 2027.1. > * B) We keep supporting the eventlet mode in the 2027.1 release as > well and only dropping support in 2028.1. > > What do you think? > > Cheers > gibi > >

1 month, 3 weeks

Re: #eventle-removal - Progress & Updates Epoxy Milestones 2-3

by Herve Beraud

Le lun. 17 févr. 2025 à 14:19, Takashi Kajinami <kajinamit(a)oss.nttdata.com> a écrit : > > In parallel to that, we think we should also have a discussion about > heat and heat-templates. The activity of these projects seems quite slow > and (do not hesitate to correct me if I'm wrong) they are more or less in a > way to be replaced with more modern ways to orchestrate OpenStack. Should > we not prioritize their deprecation or at least start a wider discussion > about their fate? > > > > Well, I'm quite surprised to see this statement without any discussion > with the heat project, > or even me who has been maintaining the project for some time. > You're right Takashi, I should have contacted you first. I apologize. My goal with that thread was simply to ensure that we are able to conduct the eventlet migration safely and not to dictate an architecture or a decision. I simply wanted to ensure that this migration effort wouldn't rely on the shoulders of only one person and ensure that we assign the needed resources in time. but I admit that I did it clumsily. and again I apologize for that. In the case some vendors would already have some tracks to replace heat by an alternative, I wanted to weigh the pros and cons of a potential global replacement rather than an eventlet costly migration. But, now that the nail is hammered in, the sooner the discussion, the better resource allocation, the smoother the migration. In addition to that, when I wrote my original sentence, especially the part about "more modern ways to orchestrate OpenStack" I was only supposing that the recent OpenShift move (RHOSO) by Red Hat would open the doors of an alternative orchestration of OpenStack through OpenShift mechanisms. But I had a RedHat centric point of view concerning this point, and I didn't consider the feasibility and all the vendors and the community sides.This is an abusive generalization on my part. You should also notice that I speak on my own concerning this point, there is yet no official RedHat downstream discussions/positions about removing Heat either. To finish, given all the various discussions I recently had following this thread, it seems, at first glance, that the migration is feasible and not so hard, so that's good news. I see that you recently proposed a patch to start, in some aspects, the removal of eventlet from heat https://review.opendev.org/c/openstack/heat/+/932925, that's a good start. Thank you Takashi for all your hard work on Heat and in OpenStack in general and sorry again for the misunderstanding generated by this thread. > Yes. Heat is not very active. However it is used in multiple deployments > or products. > The User survay data[1] shows 57% of deployment is using heat. I know > there are several > vendors using it in their product. However the sad fact is that most of > them rarely > prioritize improvement or even maintenance of Heat recently. > [1] https://www.openstack.org/analytics/ > > I've seen number of people insisting that Heat can be "easily" replaced by > any other > "much better" tools such as ansible. Yes. It may be easy to create > resources using > such tools, but you likely find multiple problems when you try to modify > your resource > stacks, like reducing number of servers. You should be always careful > about the resource > dependencies (for example you can not delete a volume before you detach it > from an instance) > and implementing the correct dependency is usually messy unless your tool > can detect > diff and construct the appropriate order of resource update, which heat > does. > I saw number of softwares, especially NFV managers, were built on Heat in > the past and > I don't know how many of these could have migrated away from heat really. > > However I'm happy to retire it if there is a common consensus within the > community > that heat is no longer a thing and can be easily replaced by something > much better. > I'm quite interested in learning what 57% of deployments may use next to > replace heat, > so that I know what I can/should focus instead of Heat (or even OpenStack) > :-). > > > > ## Call to Action > > > > Epoxy is a SLURP series, and as we are close from lib freeze and from > milestone 3, that's the right time to prioritize your deprecations in your > deliverables in view of removing these pieces with non-SLURP series. The > sooner they are deprecated the better. > > > > ## Important Dates > > > > Please do not hesitate to join us during our bi-weekly meeting on > #openstack-eventlet-removal. > > Bring your own topics and do not hesitate to ask questions. > > > > All the details are available in the links below: > > - https://wiki.openstack.org/wiki/Eventlet-removal#Recurring_Events < > https://wiki.openstack.org/wiki/Eventlet-removal#Recurring_Events> > > - https://etherpad.opendev.org/p/epoxy-eventlet-tracking < > https://etherpad.opendev.org/p/epoxy-eventlet-tracking> > > > > ## Final Thoughts > > > > This series strongly demonstrated the feasibility to remove our > dependency to Eventlet. There is still a long way to go but the path is now > well cleared. Do not hesitate to take example on the ongoing efforts, and > If there are any questions or if you need assistance with your project’s > transition away from Eventlet, please join the discussion on the > #openstack-eventlet-removal OFTC channels . We will be happy to help you! > > > > Thank you for your dedication and hard work! > > > > -- > > Hervé Beraud > > Senior Software Engineer at Red Hat > > irc: hberaud > > https://github.com/4383/ <https://github.com/4383/> > > > > -- Hervé Beraud Senior Software Engineer at Red Hat irc: hberaud https://github.com/4383/

5 months, 2 weeks

[neutron] Bug deputy report (week starting on May 19)

by Elvira Garcia Ruiz

Hi folks! Here you have the list of bugs reported for Neutron during last week. It’s been a busy week. There are a couple of them that I left undecided since I don’t feel knowledgeable enough about the issue. We can discuss them at the team meeting if that's ok. (19 May - 25 May) Critical --------- - https://bugs.launchpad.net/neutron/+bug/2111262 [wntp] test_attach_qos_port_to_vm_with_another_port should create VMs on different computes Fix merged by Eduardo Olivares https://review.opendev.org/c/x/whitebox-neutron-tempest-plugin/+/950296 High ------ - https://bugs.launchpad.net/neutron/+bug/2111272 security group delete fails with PgDelCommand.*exceeded timeout 180 seconds, cause: Result queue is empty Unassigned - https://bugs.launchpad.net/neutron/+bug/2111414 [eventlet-removal] Remove the usage of eventlet in unit tests Fix proposed by Rodolfo https://review.opendev.org/c/openstack/neutron/+/950502 - https://bugs.launchpad.net/neutron/+bug/2111417 [eventlet-removal] Remove the usage of eventlet in functional tests Fix proposed by Rodolfo https://review.opendev.org/c/openstack/neutron/+/950521 - https://bugs.launchpad.net/neutron/+bug/2111422 [eventlet-removal] Remove the usage of eventlet in fullstack tests Unassigned - https://bugs.launchpad.net/neutron/+bug/2111498 [OVN] Mechanism driver fails to fix router_ports: KeyError 'neutron:provnet-network-type' Unassigned. Set this as high but I would like to have someone else take a look at this one. - https://bugs.launchpad.net/neutron/+bug/2111593 [ovn] Race between FIP NAT entry creation and OVN port status update Fix proposed by Dmitrii Shcherbakov https://review.opendev.org/c/openstack/neutron/+/950757 Medium ----------- - https://bugs.launchpad.net/neutron/+bug/2111475 openstack network agent list cannot return new added metadata agent Fix proposed https://review.opendev.org/c/openstack/neutron/+/950624 (needs to be proposed on master) - https://bugs.launchpad.net/neutron/+bug/2111572 [OVN] OVN ML2 mech driver forces port update to networking generic switch (NGS) on OVS restart Unassigned - https://bugs.launchpad.net/neutron/+bug/2111584 Failed to get list of ports due to removed network Unassigned. I set it as low hanging fruit since the issue is quite spotted already. Low ------ - https://bugs.launchpad.net/neutron/+bug/2111330 [FT] Error in ``test_pb_type_empty`` test Unassigned Wishlist ----------- - https://bugs.launchpad.net/neutron/+bug/2111276 [RFE] Integrate OVN BGP capabilities into Neutron OVN driver Unassigned. Should be discussed in the drivers meeting. Undecided --------------- - https://bugs.launchpad.net/neutron/+bug/2111254 [ovn] distributed fip missing external_mac Unassigned. I asked froyo if he could take a look at this since the reporter encountered this on an env with octavia. - https://bugs.launchpad.net/neutron/+bug/2111496 Neutron port stuck in DOWN state after update router external connectivity Unassigned - https://bugs.launchpad.net/neutron/+bug/2111660 OVN_AGENT_NEUTRON_SB_CFG_KEY doesn't set when Neutron OVN Agent starts Unassigned Best regards, Elvira

2 months, 2 weeks

Re: [eventlet-removal]When to drop eventlet support

by Jay Faulkner

On 6/13/25 5:08 AM, Balazs Gibizer wrote: > Hi Stackers! > > I would like to sync about the planned timeline of dropping eventlet > support from OpenStack / Oslo. > > Nova definitely needs at least the full 2026.1 cycle to have a chance > to transform the nova-compute service. But this plan already feels > stretched based on the progress in the current cycle. So being > conservative means we need the 2026.2 cycle as a buffer. > > Nova would like to keep a release where we support both eventlet and > threading in parallel. So that operators can do the switching from > eventlet to threading outside of the upgrade procedure. (This was an > explicit request from them during the PTG). So 2026.2 could be that > version where nova fully supports both concurrency mode, while > eventlet can be marked deprecated. Then the 2027.1 release could be > the first release dropping eventlet. > > However we need to align with the SLURP upgrade as well. 2026.1 is a > SLURP. But in that release Nova might not be ready to have all > services running in threading mode. So the 2026.1 - 2027.1 SLURP > upgrade would force the operators to change the concurrency mode > during the upgrade itself. > > I see two ways forward: > * A) We say that operators who want to do the concurrency mode change > outside of an upgrade could not skip the 2026.2 release, i.e. they > cannot do SLURP directly from 2026.1. to 2027.1. > * B) We keep supporting the eventlet mode in the 2027.1 release as > well and only dropping support in 2028.1. Keeping eventlet running for that long is not something that is a worthy investment of time. The oslo libraries are showing a deprecation of 2026.2, I've been using that date as the target for all Ironic work as well. Beyond the oslo team (who I don't speak for), there are folks -- like Itamar on behalf of GR-OSS -- who are doing work behind the scenes to keep eventlet running - barely. I do not expect the GR-OSS investment in this work to extend much past the midpoint of 2026. My $.02, Jay Faulkner Open Source Developer G-Research Open Source Software

2 months

Re: [oslo] Specs proposal to use cotyledon and futurist.

by Daniel Bengtsson

On 2024-06-24 13:22, smooney(a)redhat.com wrote: > On Mon, 2024-06-24 at 12:00 +0200, Daniel Bengtsson wrote: > im in favour of that approch and left some suggestions regarding the mechanics of how > we could do that in the review. basically make cotyledon optional in this cycle > make it the default in 2025.1 and deprecate the eventlet backend > remove the eventlet support in 2025.2 or 2026.1 based on the > progress of the eventlet removal work in the consuming projects. Thanks a lot Sean for your feedback. That sounds good and I will update my proposal. > we could either take the same approch with oslo.service or add a config option in oslo.service to choose > the backbend. I think it's a good approch. Let's do it. > that would allow applications to move individual executable as that executable supprot the new backend. > i.e. nova-scheduler could move to the new backbend before nova-compute. Yes right. > if there is a config option or environmental vairable either in the lib or applications that would > allow use to experiment with the new backend in the ci on a per job basis too but thats just > a side effect of keeping both implementations in oslo.service for a few release. Yes that sounds good. -- Daniel Bengtsson Software Engineer

1 year, 1 month

Re: [devstack][nova][cinder][ironic][glance][swift][neutron][all] Deprecating/removing non-uWSGI deployment mechanisms?

by Tobias Urdin

This is indeed interesting times, thanks for driving the discussion on Eventlet and everything that follows down that rabbit hole, Herve! I’ve always wondered why there is no oslo.api part that consolidated the usage of Flask, Pecan etc the same way that oslo.service were meant to consolidate the service layer (but being pluggable with a “backend”). Sorry for the noice thinking out loud, there probably is (by now) ancient mailing list thread, blueprint or wiki article about that somewhere. /Tobias > On 30 Oct 2024, at 15:55, Herve Beraud <hberaud(a)redhat.com> wrote: > > > > Le mer. 30 oct. 2024 à 13:05, Stephen Finucane <stephenfin(a)redhat.com <mailto:stephenfin@redhat.com>> a écrit : >> On Mon, 2024-10-28 at 17:58 +0100, Herve Beraud wrote: >>> Hey folks, >>> >>> FYI, we think that his topic overlaps a bit with some aspects of the Eventlet Removal Initiative. Indeed, removing Eventlet means removing our usage of the WSGI features offered by Eventlet. >>> >>> https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack… >>> >>> I invite you to read this parallel discussion and I wanted to share with you the HTTP SGI working group => https://wiki.openstack.org/wiki/Eventlet-removal#The_HTTP_SGI_Working_Group >>> >>> IMO we could capitalize from each other by having cross discussion. >>> Choosing the next SGI candidate will dictate how we deal with HTTP for the coming decade, so I think we have to put our focus on it ASAP. >>> We created comparisons between the alternatives at our disposal, here is an example with the HTTP/SGI comparison https://wiki.openstack.org/wiki/SGI-servers-comparison >> >> I took a read through these. Just to be clear, are we suggesting projects change their web frameworks or that DevStack/DevStack plugins change the WSGI server used? If so, why? > > As Eventlet is going to be removed, its WSGI server too, I think we will mostly try to find a standardized way to replace it. > > On our side I think the discussion is mostly about projects relying on Eventlet needing to change their WSGI server and so it potentially opens the doors of a wider discussion, to avoid finishing with 10 different ways to serve HTTP. Maybe uWSGI and WSGI is a credible short term solution, but if components express needs to explore something like ASGI or other alternatives to uWSGI, then I think we should have some consultations, because in some way these 2 topics (DevStack and Eventet removal) overlap. > > The question is not about requesting to change the DevStack WSGI server, but if we decide to follow some uniformity, then the WSGI aspect of DevStack would also have to join the discussion about standardization. > > Some ASGI stacks can handle sync and async at the same time, so, if people push this path and if the discussion is going this way, maybe it would be worth the effort to transform DevStack too. > > On the other hand, if DevStack encourages uWSGI, probably uWSGI would be the default option for escaping from Eventlet, but locking us in a limited support of async. As uWSGI is in maintenance mode, we should not expect new updates from uWSGI to introduce/increase async support. > >> I understand that some projects might want to explore ASGI, which would necessitate something other than our current Apache+mod_wsgi+uWSGI combo for the server and whatever web framework they're using for the server, but assuming they are going to continue using WSGI then any change of server or framework would seem to be be secondary (if not entirely unrelated) to the eventlet removal goal. While e.g. nova might have a few reasons to explore long-term alternatives to Paste+WebOb, eventlet removal doesn't feel like one of them. >> >> Stephen >> >>> Please find all the useful details in the official wiki: https://wiki.openstack.org/wiki/Eventlet-removal >>> We strongly encourage a collaborative decision, to avoid having multiple ways to manage things. >>> This specialized working group would be responsible for producing a unified approach that will simplify maintenance and enhance user experience. >>> >>> Thanks for your time and consideration. >>> >>> >>> Le jeu. 17 oct. 2024 à 13:06, Stephen Finucane <stephenfin(a)redhat.com <mailto:stephenfin@redhat.com>> a écrit : >>>> On Wed, 2024-10-16 at 14:16 +0200, Tobias Urdin wrote: >>>> > Hello, >>>> > >>>> > This is an interesting topic and IMO has been in a weird state for years >>>> > and years and I can only deduct that this has been because of, yet >>>> > again, the broad spectrum of ways that OpenStack can be deployed. >>>> > >>>> > Every guide, every deployment tool, every project has their own ways; >>>> > supported way, and recommend way, of deploying and multiple projects has >>>> > either bugs with one but no the other or the other way around making >>>> > deployment even harder. >>>> > >>>> > Specially on this topic though, this drops testing of one of those ways, >>>> > is the plan/should we interpret this as a guideline on what developers >>>> > need to test their features? Should we take this as advice on how to deploy >>>> > the services and start dropping any usage of mod_wsgi in deployment >>>> > tools? If no, should we expect mod_wsgi to break when eventlet is phased >>>> > out because it will not be tested? >>>> > >>>> > I think this topic really need to be a specification (and perhaps a community >>>> > goal) around what deliverables should support. >>>> > >>>> > If we want to take measures, perhaps it's time to consolidate and minimize the headache for deployers and just drop everything except for one way, the right way (that we decide and then stick with). > > I think our main question is the same as the one expressed by Tobias in this thread ^. Consolidate. But consolidate without ignoring potential coming async needs. > >>>> > >>>> > I don't want this to sound like throwing shade at this effort, the >>>> > opposite I want it to move along, but in a clear way, and just perhaps >>>> > we should just drop everything and use oslo.service and go back to how >>>> > it was before mod_wsgi was recommended now that we're getting rid of >>>> > eventlet and just deploy more services instead of using something like >>>> > mod_wsgi to handle N copies of services. >>>> >>>> In theory, so long as services support WSGI then it shouldn't matter what we >>>> WSGI HTTP server we use: they all speak WSGI. Sure, the configuration files are >>>> going to look different and the performance and feature sets will vary, but IMO >>>> that's a deployment problem/decision rather than something the services (or our >>>> CIs) need to worry about. > > And as you said, having plurality in our WSGI servers would lead us to deployment diversity. > If we put the ASGI aspect on top of that, we will obtain another layer of complexity. > I think the current DevStack discussion is in some sort the other face of the eventlet removal piece > > Let me know if I answered your question. > >>>> I certainly don't feel *I* am in a position to state >>>> that e.g. gunicorn should be preferred to a long-standing alternative like uWSGI >>>> or mod_wsgi, an ASGI-first implementation like Daphne or uvicorn, or a newcomer >>>> like nginx unit, and this is a position apparently also shared by both the >>>> Django [1] or Flask [2] communities (to pick two well-known examples). Maybe >>>> deployers could share feedback on their chosen solution and put guidance in the >>>> deployment docs but again, that's out of scope for a DevStack change. >>>> >>>> In addition, I should highlight that we are not currently testing against >>>> anything but uWSGI and, in rare cases, eventlet server. A grok for the various >>>> config options I mentioned reveals nothing of interest [3][4] (for example, the >>>> only override of 'WSGI_MODE' I can find is in monasca-api which, based on recent >>>> attempts to push stuff to monasca projects, is either dead or on life support). >>>> Nothing is changing here and for the most part we're just removing dead code and >>>> pushing a few long-running efforts forwards towards their conclusion. This is >>>> also true for the removal of support for deploying with eventlet server: as I >>>> noted, neither Cinder nor Nova actually test these paths any more, and Neutron >>>> is well on the way to doing the same. The only services that appear to be long- >>>> term interested in testing with eventlet server are not those interested in >>>> using eventlet for their API service but rather those that need to support a >>>> standalone mode, with multiple servers provided by a single binary. Again, as I >>>> noted below, this list includes Glance, Ironic, and possibly Swift (???). >>>> There's definitely a discussion to be had around what the replacement for >>>> eventlet server is for these projects, but that's being tackled elsewhere [5] >>>> and is not something I want to wade into here. >>>> >>>> I hope this clarifies my suggestions here, >>>> Stephen >>>> >>>> [1] https://docs.djangoproject.com/en/5.1/howto/deployment/wsgi/ >>>> [2] https://flask.palletsprojects.com/en/2.3.x/deploying/ >>>> [3] https://codesearch.opendev.org/?q=ENABLE_HTTPD_MOD_WSGI_SERVICES >>>> [4] https://codesearch.opendev.org/?q=WSGI_MODE%3D >>>> [5] https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack… >>>> >>>> > >>>> > /Tobias >>>> > >>>> > On Wed, Oct 16, 2024 at 11:12:03AM UTC, Stephen Finucane wrote: >>>> > > o/ >>>> > > >>>> > > tl;dr: I'd like to remove the ability to deploy services under mod_wsgi from >>>> > > DevStack. I'd also like to remove the ability to deploy services under eventlet, >>>> > > where this feature is not currently being tested, and deprecate it where it is. >>>> > > >>>> > > I took a foray through DevStack last week and realised that, depending on the >>>> > > service in question, there are currently 3 possible ways an API can be deployed >>>> > > by DevStack: >>>> > > >>>> > > * Eventlet server >>>> > > * Apache + uWSGI >>>> > > * Apache + mod_wsgi >>>> > > >>>> > > In addition, there are a number of overlapping config options that could be set >>>> > > to modify which of these was in use: >>>> > > >>>> > > * ENABLE_HTTPD_MOD_WSGI_SERVICES >>>> > > * WSGI_MODE >>>> > > * Service-specific options like NOVA_USE_MOD_WSGI, CINDER_USE_MOD_WSGI etc. >>>> > > >>>> > > Potential confusion aside, there are two issues I see with this. Firstly, and >>>> > > most obviously, we are working on eventlet removal, which will necessarily >>>> > > involve eventlet server removal [1]. In addition, there is a goal [2][3] to >>>> > > remove use of '.wsgi' scripts in favour of Python module paths. Quite a few >>>> > > services have migrated to this already, and those that haven't are going to need >>>> > > to do so by time pip 25.0 comes out (since that removes the deprecated legacy >>>> > > editable install flow [4] meaning these files will not be generated by pbr and >>>> > > DevStack deployments will start failing...you have been warned). However, >>>> > > mod_wsgi need .wsgi scripts. I didn't realise we cared about mod_wsgi in >>>> > > DevStack still before last week, so to complete the wsgi script -> module >>>> > > migration for services that can be deployed with mod_wsgi (e.g. Keystone), we're >>>> > > going to have to either (a) package a .wsgi script in DevStack or (b) remove the >>>> > > ability to deploy with mod_wsgi. >>>> > > >>>> > > My immediate thought on this was to simply remove all non-uWSGI deployment paths >>>> > > immediately and deprecate the config options for removal to force DevStack >>>> > > plugins to adapt. However, some services still want to test eventlet server for >>>> > > their API while they stabilise support for standard WSGI-based deployments >>>> > > (neutron), while others explicitly rely on evenlet to generate a single >>>> > > standalone binary (ironic, glance, ...). That means we can't just go remove >>>> > > everything now and must instead take a phased approach. I would therefore like >>>> > > to propose we do the following: >>>> > > >>>> > > * Remove the ability to deploy services under mod_wsgi from DevStack and >>>> > > deprecate/remove the WSGI_MODE flag. To be clear, other deployment tools can >>>> > > continue to use mod_wsgi but DevStack won't. >>>> > > * Entirely remove the ability to deploy under eventlet from services that are >>>> > > not currently testing this. This includes Nova and Cinder. >>>> > > * Invert the default for services that are testing eventlet, so that they test >>>> > > with uWSGI by default now and jobs will need to opt-in to eventlet rather >>>> > > than opt-in to uWSGI. I think this just affects Neutron. >>>> > > * Optionally, and likely only one Neutron is no longer testing eventlet (next >>>> > > cycle?), deprecate ENABLE_HTTPD_MOD_WSGI_SERVICES and {SERVICE}_USE_MOD_WSGI >>>> > > config options entirely and replace it with {SERVICE}_STANDALONE options like >>>> > > Glance has. This will affect Ironic and maybe more. >>>> > > >>>> > > I have proposed a series that will do much of this. The WIP patches indicate the >>>> > > things that I am less clear about, such as Swift's readiness for deploying under >>>> > > uWSGI. I would be grateful if folks from the individual service teams could take >>>> > > a look and let me know what they think: >>>> > > >>>> > > https://review.opendev.org/c/openstack/devstack/+/932193/1 >>>> > > >>>> > > Cheers, >>>> > > >>>> > > Stephen >>>> > > >>>> > > [1] https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack… >>>> > > [2] https://review.opendev.org/c/openstack/governance/+/902807 >>>> > > [3] https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack… >>>> > > [4] https://ichard26.github.io/blog/2024/08/whats-new-in-pip-24.2/ >>>> > > >>>> > >>>> >>> >>> >>> >>> -- >>> Hervé Beraud >>> Senior Software Engineer at Red Hat >>> irc: hberaud >>> https://github.com/4383/ >>> >> > > > -- > Hervé Beraud > Senior Software Engineer at Red Hat > irc: hberaud > https://github.com/4383/

9 months, 2 weeks

Re: Upstream Oslo IRC Meetings Are Back.

by Herve Beraud

Le lun. 4 nov. 2024 à 13:51, Takashi Kajinami <kajinamit(a)oss.nttdata.com> a écrit : > > > On 11/4/24 6:00 PM, Herve Beraud wrote: > > > > > > Le jeu. 31 oct. 2024 à 18:38, Takashi Kajinami < > kajinamit(a)oss.nttdata.com <mailto:kajinamit@oss.nttdata.com>> a écrit : > > > > I noticed that eventlet removal meeting is independent from > > the oslo meeting proposed in this thread. I'm ok to have dedicated > > slot to discuss oslo specific topics but may need to have clear scope > > definition. (Since it was mentioned that eventlet removal is the core > > topic we want to discuss in this meeting, right ?). > > > > > > Oslo meetings are Oslo meetings, isn't the lifecycle of Oslo and the > Oslo deliverables a clear scope? Oslo owns more than 40 deliverables, I > don't think it would be difficult to find Oslo things to discuss. Another > option would be to follow the series agenda, and to base our Oslo meetings > over the series lifecycle (milestones, FF, etc.). > > > > Are people supposed to use this meeting agenda ( > https://wiki.openstack.org/wiki/Meetings/Oslo < > https://wiki.openstack.org/wiki/Meetings/Oslo>) to put their topics and > to retrieve the topics you propose? > > > > If you propose to base our discussions on a series lifecycle, maybe it > could worth basing our meetings on an agenda like the one used by the > release team https://etherpad.opendev.org/p/epoxy-relmgt-tracking,The < > https://etherpad.opendev.org/p/epoxy-relmgt-tracking,The> release team > created tooling to generate this kind of etherpad, perhaps you could reuse > it... > > I totally agree with you about these points and these are exactly what I'd > propose for oslo specific > meeting. I just wanted to make sure that Daniel's expectation is similar, > because in his initial email > sounded that the eventlet removal is the key motivation to restore the > meeting. > > > > Concerning Eventlet. Eventlet may impact Oslo in some ways, but Oslo > meetings are not the right place to host all the Eventlet discussions. > Eventlet discussions will cover a wide range of topics, from neutron, to > packaging, passing by requirements, and surely also Oslo at some points, so > I don't think Oslo meetings is the right place. > > Nova, Neutron, Glance and surely many other deliverables already have > internal discussions about Eventlet in their own IRC meetings, IMO Oslo > should follow the same path. > > +1 > > > Regarding the time slot, EMEA/NA slots might work better for me > because > > I can join these after I settle down my own things, but I think it's > > generally got to have more Asia friendly slots if anyone from Asia > > (especially east-Asia) is interested in joining us. > > > > > > You are the chair [1] of the Oslo meeting, so "joining us" mostly means > "joining you". Asia time slots are before EMEA/NA so if you have your "own > things before", my question is: would you be able to join and manage the > Asia time slot? If your answer is no, IMO, it is useless to propose an Asia > time slot, as people will wait for the meeting chair. > > This is the question to Daniel who is the primary chair (though I can help > when he is not available > on best effort basis). I wanted to make you aware of my preference > assuming you may count me > as a participant from Asia. > Thanks for pointing out that point, indeed, Daniel is the primary chair. I misread the "sender" of your previous answer. I wrote my previous response thinking that the email was sent by Daniel, that's why I spoke about the meeting chair and about the duties related to this role. My bad. > > > > > It is up to you. > > > > [1] https://meetings.opendev.org/#Oslo_Team_Meeting < > https://meetings.opendev.org/#Oslo_Team_Meeting> > > > > > > On 10/31/24 7:07 PM, dbengt(a)redhat.com <mailto:dbengt@redhat.com> > wrote: > > > > > > > > > On 10/30/24 5:57 PM, Ghanshyam Mann <gmann(a)ghanshyammann.com > <mailto:gmann@ghanshyammann.com>> wrote: > > >> ++ on alternate TZ meetings, and that way, EU and Asia TZ can be > covered in one of the meetings. > > >> To keep it simple, we can have separate doodle poll for each TZ > meeting. > > > Ok so maybe instead we can have one meeting per week. As you > proposed like one for the Europeean and Asia and one for the us? I have > create a first UTC pool here[1] afternoon and here[2] you have the morning > one. > > > > > > [1] https://www.vyte.in/e/1cnp51e4sd < > https://www.vyte.in/e/1cnp51e4sd> [2] https://www.vyte.in/e/2j0to257cd < > https://www.vyte.in/e/2j0to257cd> > > > > > > > > > > > -- > > Hervé Beraud > > Senior Software Engineer at Red Hat > > irc: hberaud > > https://github.com/4383/ <https://github.com/4383/> > > > > -- Hervé Beraud Senior Software Engineer at Red Hat irc: hberaud https://github.com/4383/

9 months, 1 week

Re: [devstack][nova][cinder][ironic][glance][swift][neutron][all] Deprecating/removing non-uWSGI deployment mechanisms?

by Herve Beraud

Hey folks, FYI, we think that his topic overlaps a bit with some aspects of the Eventlet Removal Initiative. Indeed, removing Eventlet means removing our usage of the WSGI features offered by Eventlet. https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack… I invite you to read this parallel discussion and I wanted to share with you the HTTP SGI working group => https://wiki.openstack.org/wiki/Eventlet-removal#The_HTTP_SGI_Working_Group IMO we could capitalize from each other by having cross discussion. Choosing the next SGI candidate will dictate how we deal with HTTP for the coming decade, so I think we have to put our focus on it ASAP. We created comparisons between the alternatives at our disposal, here is an example with the HTTP/SGI comparison https://wiki.openstack.org/wiki/SGI-servers-comparison Please find all the useful details in the official wiki: https://wiki.openstack.org/wiki/Eventlet-removal We strongly encourage a collaborative decision, to avoid having multiple ways to manage things. This specialized working group would be responsible for producing a unified approach that will simplify maintenance and enhance user experience. Thanks for your time and consideration. Le jeu. 17 oct. 2024 à 13:06, Stephen Finucane <stephenfin(a)redhat.com> a écrit : > On Wed, 2024-10-16 at 14:16 +0200, Tobias Urdin wrote: > > Hello, > > > > This is an interesting topic and IMO has been in a weird state for years > > and years and I can only deduct that this has been because of, yet > > again, the broad spectrum of ways that OpenStack can be deployed. > > > > Every guide, every deployment tool, every project has their own ways; > > supported way, and recommend way, of deploying and multiple projects has > > either bugs with one but no the other or the other way around making > > deployment even harder. > > > > Specially on this topic though, this drops testing of one of those ways, > > is the plan/should we interpret this as a guideline on what developers > > need to test their features? Should we take this as advice on how to > deploy > > the services and start dropping any usage of mod_wsgi in deployment > > tools? If no, should we expect mod_wsgi to break when eventlet is phased > > out because it will not be tested? > > > > I think this topic really need to be a specification (and perhaps a > community > > goal) around what deliverables should support. > > > > If we want to take measures, perhaps it's time to consolidate and > minimize the headache for deployers and just drop everything except for one > way, the right way (that we decide and then stick with). > > > > I don't want this to sound like throwing shade at this effort, the > > opposite I want it to move along, but in a clear way, and just perhaps > > we should just drop everything and use oslo.service and go back to how > > it was before mod_wsgi was recommended now that we're getting rid of > > eventlet and just deploy more services instead of using something like > > mod_wsgi to handle N copies of services. > > In theory, so long as services support WSGI then it shouldn't matter what > we > WSGI HTTP server we use: they all speak WSGI. Sure, the configuration > files are > going to look different and the performance and feature sets will vary, > but IMO > that's a deployment problem/decision rather than something the services > (or our > CIs) need to worry about. I certainly don't feel *I* am in a position to > state > that e.g. gunicorn should be preferred to a long-standing alternative like > uWSGI > or mod_wsgi, an ASGI-first implementation like Daphne or uvicorn, or a > newcomer > like nginx unit, and this is a position apparently also shared by both the > Django [1] or Flask [2] communities (to pick two well-known examples). > Maybe > deployers could share feedback on their chosen solution and put guidance > in the > deployment docs but again, that's out of scope for a DevStack change. > > In addition, I should highlight that we are not currently testing against > anything but uWSGI and, in rare cases, eventlet server. A grok for the > various > config options I mentioned reveals nothing of interest [3][4] (for > example, the > only override of 'WSGI_MODE' I can find is in monasca-api which, based on > recent > attempts to push stuff to monasca projects, is either dead or on life > support). > Nothing is changing here and for the most part we're just removing dead > code and > pushing a few long-running efforts forwards towards their conclusion. This > is > also true for the removal of support for deploying with eventlet server: > as I > noted, neither Cinder nor Nova actually test these paths any more, and > Neutron > is well on the way to doing the same. The only services that appear to be > long- > term interested in testing with eventlet server are not those interested in > using eventlet for their API service but rather those that need to support > a > standalone mode, with multiple servers provided by a single binary. Again, > as I > noted below, this list includes Glance, Ironic, and possibly Swift (???). > There's definitely a discussion to be had around what the replacement for > eventlet server is for these projects, but that's being tackled elsewhere > [5] > and is not something I want to wade into here. > > I hope this clarifies my suggestions here, > Stephen > > [1] https://docs.djangoproject.com/en/5.1/howto/deployment/wsgi/ > [2] https://flask.palletsprojects.com/en/2.3.x/deploying/ > [3] https://codesearch.opendev.org/?q=ENABLE_HTTPD_MOD_WSGI_SERVICES > [4] https://codesearch.opendev.org/?q=WSGI_MODE%3D > [5] > https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack… > > > > > /Tobias > > > > On Wed, Oct 16, 2024 at 11:12:03AM UTC, Stephen Finucane wrote: > > > o/ > > > > > > tl;dr: I'd like to remove the ability to deploy services under > mod_wsgi from > > > DevStack. I'd also like to remove the ability to deploy services under > eventlet, > > > where this feature is not currently being tested, and deprecate it > where it is. > > > > > > I took a foray through DevStack last week and realised that, depending > on the > > > service in question, there are currently 3 possible ways an API can be > deployed > > > by DevStack: > > > > > > * Eventlet server > > > * Apache + uWSGI > > > * Apache + mod_wsgi > > > > > > In addition, there are a number of overlapping config options that > could be set > > > to modify which of these was in use: > > > > > > * ENABLE_HTTPD_MOD_WSGI_SERVICES > > > * WSGI_MODE > > > * Service-specific options like NOVA_USE_MOD_WSGI, CINDER_USE_MOD_WSGI > etc. > > > > > > Potential confusion aside, there are two issues I see with this. > Firstly, and > > > most obviously, we are working on eventlet removal, which will > necessarily > > > involve eventlet server removal [1]. In addition, there is a goal > [2][3] to > > > remove use of '.wsgi' scripts in favour of Python module paths. Quite > a few > > > services have migrated to this already, and those that haven't are > going to need > > > to do so by time pip 25.0 comes out (since that removes the deprecated > legacy > > > editable install flow [4] meaning these files will not be generated by > pbr and > > > DevStack deployments will start failing...you have been warned). > However, > > > mod_wsgi need .wsgi scripts. I didn't realise we cared about mod_wsgi > in > > > DevStack still before last week, so to complete the wsgi script -> > module > > > migration for services that can be deployed with mod_wsgi (e.g. > Keystone), we're > > > going to have to either (a) package a .wsgi script in DevStack or (b) > remove the > > > ability to deploy with mod_wsgi. > > > > > > My immediate thought on this was to simply remove all non-uWSGI > deployment paths > > > immediately and deprecate the config options for removal to force > DevStack > > > plugins to adapt. However, some services still want to test eventlet > server for > > > their API while they stabilise support for standard WSGI-based > deployments > > > (neutron), while others explicitly rely on evenlet to generate a single > > > standalone binary (ironic, glance, ...). That means we can't just go > remove > > > everything now and must instead take a phased approach. I would > therefore like > > > to propose we do the following: > > > > > > * Remove the ability to deploy services under mod_wsgi from DevStack > and > > > deprecate/remove the WSGI_MODE flag. To be clear, other deployment > tools can > > > continue to use mod_wsgi but DevStack won't. > > > * Entirely remove the ability to deploy under eventlet from services > that are > > > not currently testing this. This includes Nova and Cinder. > > > * Invert the default for services that are testing eventlet, so that > they test > > > with uWSGI by default now and jobs will need to opt-in to eventlet > rather > > > than opt-in to uWSGI. I think this just affects Neutron. > > > * Optionally, and likely only one Neutron is no longer testing > eventlet (next > > > cycle?), deprecate ENABLE_HTTPD_MOD_WSGI_SERVICES and > {SERVICE}_USE_MOD_WSGI > > > config options entirely and replace it with {SERVICE}_STANDALONE > options like > > > Glance has. This will affect Ironic and maybe more. > > > > > > I have proposed a series that will do much of this. The WIP patches > indicate the > > > things that I am less clear about, such as Swift's readiness for > deploying under > > > uWSGI. I would be grateful if folks from the individual service teams > could take > > > a look and let me know what they think: > > > > > > https://review.opendev.org/c/openstack/devstack/+/932193/1 > > > > > > Cheers, > > > > > > Stephen > > > > > > [1] > https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack… > > > [2] https://review.opendev.org/c/openstack/governance/+/902807 > > > [3] > https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack… > > > [4] https://ichard26.github.io/blog/2024/08/whats-new-in-pip-24.2/ > > > > > > > -- Hervé Beraud Senior Software Engineer at Red Hat irc: hberaud https://github.com/4383/

9 months, 2 weeks

[tc][all] OpenStack Technical Committee Weekly Summary and Meeting Agenda (2025.2/R-10)

by Goutham Pacha Ravi

Hello Stackers, We're ten weeks away from the coordinated release of OpenStack 2025.2 ("Flamingo") [1]. The feature freeze date for this release is in five weeks (2025-08-28). In the past week, the OpenStack Technical Committee did not merge any new governance changes, though a few are currently under community review. === Weekly Meeting === The last weekly meeting of the OpenStack Technical Committee took place on 2025-07-15 over IRC [2]. The TC caught up on a backlog of action items, starting with progress on the community goal to drop the use of eventlet [3]. We discussed the activity within the Monasca project team and have reached out to the PTL and core reviewers to talk about its future. The rest of the meeting focused on the maintenance of the "service-types-authority" repository. While some suggested involving the openstacksdk-core team in its maintenance, others opined that the repo should remain under TC oversight due to its governance significance—since changes affect how services are named and recognized across the ecosystem. For now, we have renewed our commitment to reviewing and merging change proposals more actively. A late tangent about the First Contact SIG’s dormancy prompted an idea to review SIG activity at the upcoming PTG in October. The next meeting of the OpenStack TC is today, 2025-07-22, at 1700 UTC. This meeting will be hosted over IRC on the #openstack-tc channel on OFTC. The agenda has been added to the meeting's wiki page [4]. I hope you'll be able to join us there. Any community member is welcome to edit the wiki page and propose new topics. === Governance Proposals === ==== Open for review ==== - os-test-images never releases | https://review.opendev.org/c/openstack/governance/+/954249 - Retire networking-midonet | https://review.opendev.org/c/openstack/governance/+/955364 - Remove Monasca from active project | https://review.opendev.org/c/openstack/governance/+/953671 - Make Eventlet removal deadlines more acceptable for operators | https://review.opendev.org/c/openstack/governance/+/952903 - Require declaration of affiliation from TC Candidates | https://review.opendev.org/c/openstack/governance/+/949432 === Upcoming Events === - 2025-07-26: OpenInfra Days, Vietnam: https://www.vietopeninfra.org/void2025 - 2025-08-06: Nominations open for OpenStack elections: https://governance.openstack.org/election/ - 2025-08-26: OpenInfra Days, Korea: https://2025.openinfradays.kr/ - 2025-08-29: Colombia OpenInfra User Group Meetup: https://www.meetup.com/colombia-openinfra-user-group/events/307096751/ - 2025-10-17: OpenInfra Summit, Paris-Saclay: https://summit2025.openinfra.org/ Thank you very much for reading! On behalf of the OpenStack TC, Goutham Pacha Ravi (gouthamr) OpenStack TC Chair [1] 2025.2 "Flamingo" Release Schedule: https://releases.openstack.org/flamingo/schedule.html [2] TC Meeting IRC Log 2025-07-15: https://meetings.opendev.org/meetings/tc/2025/tc.2025-07-15-17.00.html [3] Eventlet removal goal timeline changes: https://review.opendev.org/c/openstack/governance/+/952903 [4] TC Meeting Agenda, 2025-07-22: https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Next_Meeting

3 weeks, 1 day

Re: [eventlet-removal]When to drop eventlet support

by Balazs Gibizer

On Sat, Jun 14, 2025 at 1:24 AM <thomas(a)goirand.fr> wrote: > > > On Jun 13, 2025 20:52, Jay Faulkner <jay(a)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) >

1 month, 4 weeks

openstack-discuss search results for query "#eventlet-removal"