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

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) >

6 months, 2 weeks

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

by smooney＠redhat.com

On Mon, 2024-06-24 at 12:00 +0200, Daniel Bengtsson wrote: > Hi there, > > Further to my previous mail, I have decided to create a specs > proposal[1] within oslo. The idea is to use cotyledon and futurist in > oslo.service and not to deprecate the project. 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. oslo messaging has a configurable executor https://github.com/openstack/oslo.messaging/blob/0d3338fd1d0094150491f81955… which the calling appllication initalise https://github.com/openstack/nova/blob/master/nova/rpc.py#L220-L226 we could either take the same approch with oslo.service or add a config option in oslo.service to choose the backbend. 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. 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. > Please don't hesitate to > send me feedback. > > [1] https://review.opendev.org/c/openstack/oslo-specs/+/922597 >

1 year, 6 months

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

by Goutham Pacha Ravi

Hello Stackers, We're eleven weeks away from the date of the coordinated release of OpenStack 2025.2 ("Flamingo") [1]. The feature freeze date for this release cycle is 2025-08-28. OpenStack project teams are busy working on and polishing features to meet this deadline. In the past week, we marked the shade and os-client-config packages as deprecated [2]. The functionality provided by these two packages has long been available through openstacksdk. We don't plan to create any new releases for these packages unless critical bugs are discovered. Besides that, there have been no significant governance updates; however, several proposals are under community review. As part of the OpenInfra Foundation's transition under the Linux Foundation, your individual membership must be renewed. The OIF staff have made this a super-easy one-click process [3]. Please complete this by 2025-07-19 to contest or vote in the next OIF Board elections. OpenStack's own PTL and TC elections will occur between 23:45 UTC on 2025-08-27 and 23:45 UTC on 2025-09-17 [4]. To contest or vote in these elections, you must renew your Foundation membership by 00:00 UTC on 2025-08-20. Don't wait—this process only takes a couple of minutes! === Weekly Meeting === The last weekly IRC meeting of the OpenStack TC took place on 2025-07-08 [5]. We noted that consensus is emerging on the updated Eventlet removal timelines [6]. We followed up on the removal of all references to the Contributor License Agreement from governance docs and OpenStack manuals. There may still be some references lurking in various project documentation websites. We request contributors to file bugs or submit simple documentation updates to switch these references to the Developer Certificate of Origin [7]. OpenStack CI jobs saw some multinode hiccups over the week due to bugs in zuul-launcher. These have been resolved by the OpenDev Infra team, and CentOS/Rocky 10 along with Debian Trixie node images are expected to be served by zuul-launcher soon. The proposal to retire Monasca [8] was discussed at length. While the project has been inactive for several cycles, the TC agreed to give maintainers a chance to state their intentions before moving ahead with retirement. We also agreed that we need better visibility into inactive projects for users and operators. We'll be tweaking the appropriate badges that show up on the repositories and adding notices on project documentation websites. Lastly, we were updated that work is underway to fully remove CLA references from Gerrit. The next weekly meeting of the OpenStack TC is on 2025-07-15 at 17:00 UTC. This meeting will be hosted over IRC in OFTC's #openstack-tc channel. Please find the meeting details, including the agenda, on the meeting's wiki page [9]. I hope you'll be able to join us. === Governance Proposals === ==== Merged ==== - Deprecate shade, os-client-config | https://review.opendev.org/c/openstack/governance/+/953549 ==== Open for review ==== - 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 - os-test-images never releases | https://review.opendev.org/c/openstack/governance/+/954249 === Upcoming Events === - 2025-07-19: OpenInfra Days, Indonesia: https://2025.openinfra.id/ - 2025-07-26: OpenInfra Days, Vietnam: https://www.vietopeninfra.org/void2025 - 2025-08-06: Nominations open for OpenStack elections: https://governance.openstack.org/election/ === How to Contact the TC === You can reach the TC in several ways: - Email: send an email with the tag [tc] on this mailing list. - Ping us using the tc-members keyword on the #openstack-tc IRC channel on OFTC. - Join us at our weekly meeting: The Technical Committee meets every week on Tuesdays at 17:00 UTC [9]. 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] Deprecation of shade and os-client-config: https://review.opendev.org/c/openstack/governance/+/953549 [3] Renew OIF membership: https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack… [4] OpenStack Election Schedule: https://summit2025.openinfra.org/a/schedule [5] TC Meeting IRC Log 2025-07-08: https://meetings.opendev.org/meetings/tc/2025/tc.2025-07-08-17.00.html [6] Eventlet removal timeline proposal: https://review.opendev.org/c/openstack/governance/+/952903 [7] DCO instructions: https://docs.openstack.org/contributors/common/dco.html [8] Retiring monasca: https://review.opendev.org/c/openstack/governance/+/953671 [9] TC Meeting Agenda, 2025-07-15: https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Next_Meeting

5 months, 2 weeks

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

by Tobias Urdin

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. /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/ >

1 year, 2 months

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

by Arnaud Morin

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(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) > > >

6 months, 2 weeks

Re: [eventlet-removal][Neutron] neutron-dynamic-routing project status

by Brian Haley

Hi, Sorry for the top-post but just wanted to ask again if someone familiar with neutron-dynamic-routing is able to take on this task of making it work without eventlet. I did just push an update to the patch [2] but I do not expect it to fix the issues. Please reach-out to myself or Rodolfo and we can give you some guidance. Thanks, -Brian On 11/19/25 6:53 AM, Rodolfo Alonso Hernandez wrote: > Hello all: > > Since [1], Neutron removed any dependency of "eventlet", including > several auxiliary methods used by other projects, in particular neutron- > dynamic-routing. > > We have been trying to clean-up this project, updating the requirements > (removing eventlet, updating os-ken) and refactoring the DR agent > classes (similar to what was done in the DHCP or L3 agents). But the DR > agent is still failing [2], maybe due to an incorrect implementation in > os-ken. However, due to the limited time we have, we cannot investigate it. > > *This email is a request for assistance in getting the users/developers > of that project to remediate the code and remove the eventlet > dependency.* This topic and the resolution taken was mentioned in the > last Neutron meeting [3]. > > Regards. > > [1]https://review.opendev.org/c/openstack/neutron/+/961210 <https:// > review.opendev.org/c/openstack/neutron/+/961210> > [2]https://review.opendev.org/c/openstack/neutron-dynamic-routing/ > +/956747 <https://review.opendev.org/c/openstack/neutron-dynamic- > routing/+/956747> > [3]https://meetings.opendev.org/meetings/networking/2025/ > networking.2025-11-18-14.01.log.html#l-139 <https:// > meetings.opendev.org/meetings/networking/2025/ > networking.2025-11-18-14.01.log.html#l-139>

4 weeks, 2 days

Re: #eventlet-removal Thank you for 2025

by Thierry Carrez

Herve Beraud wrote: > [...] > On behalf of this community initiative, thank you for your commitment > throughout this year. You have proven, once again, that necessary work — > even when it does not immediately shine — is often the work that matters > the most. +1000 And thanks to you, Hervé, for coordinating and pushing this critical effort! Thierry

2 weeks

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

by Sean Mooney

On 16/06/2025 13:09, Thomas Goirand wrote: > On 6/14/25 05:07, Dmitriy Rabotyagov wrote: >> >> >> On Sat, 14 Jun 2025, 01:24 , <thomas(a)goirand.fr >> <mailto:thomas@goirand.fr>> wrote: >> >> >> >> 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. >> Cheers, >> >> >> Well, at least some class of bugs might be already known and >> operators might be willing to accept them, while the new ones could >> be not known by project maintainers and take quite some time to >> realize and patch. >> >> So being able to rollback to old behavior might save the day. > > This is FUD. IMO, either upstream OpenStack provides a working setup, > either it's not. sayint its FUD is not helpful. we got a driect ask form operator and soem core to not do a hard switch over. and while i wanted to only support one model for each binary at a time we were sepcificly ask to make it configurable. > In the later case, your only available action is help fixing bugs. It > is not up to the operators to double-guess what may or may not work. correct we are not planning to document how to change mode we were planning to only use this configuration in ci and operator would be told for a given release deploy this way. this is an internal impelation detail however we are not prepared to deprecate usign eventlet until we are convicned that we can run properly without it. > For beginners, this would be a horrible nightmare if default options > simply wouldn't work. We *must* ship OpenStack working by default. no one is suggesting we do otherwise. > > Cheers, > > Thomas Goirand (zigo) >

6 months, 2 weeks

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

by Stephen Finucane

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/ > > >

1 year, 2 months

[neutron] bug deputy report for 2025w10

by Bence Romsics

Hi Neutron Team! Last week we had the following new bug reports: Gate failures: * https://bugs.launchpad.net/neutron/+bug/2100776 test_securitygroup(ovs-openflow) fullstack test random failure with Time out exception unassigned * https://bugs.launchpad.net/neutron/+bug/2101165 Random failure in test_established_tcp_session_after_re_attachinging_sg unassigned * https://bugs.launchpad.net/neutron/+bug/2101166 Random failure in dvr ovs grenade jobs to ping vm post upgrade unassigned * https://bugs.launchpad.net/neutron/+bug/2100806 Intermittent test_batch_notifier failure fix proposed: https://review.opendev.org/c/openstack/neutron/+/943212 High: * https://bugs.launchpad.net/neutron/+bug/2101150 User who is not owner of the SG can create/delete rules in the shared SG assigned to Slawek * https://bugs.launchpad.net/neutron/+bug/2101063 [OVN] min-bw QoS policy cannot be defined alone, exception raised fix proposed: https://review.opendev.org/c/openstack/neutron/+/943664 Medium: * https://bugs.launchpad.net/neutron/+bug/2101140 [OVN] Make LSP up/down events processing resilient to IDL disconnections fix proposed: https://review.opendev.org/c/openstack/neutron/+/943404 * https://bugs.launchpad.net/neutron/+bug/2101162 [OVN] Use HA_Chassis_Group for tunnelled gateway network LRPs WIP fix: https://review.opendev.org/c/openstack/neutron/+/938134 * https://bugs.launchpad.net/neutron/+bug/2100938 Assign HA_Chassis_Group to all LRPs for tunnelled gateway assigned to Rodolfo Eventlet removal: * https://bugs.launchpad.net/neutron/+bug/2101076 [eventlet-removal] Remove the usage of eventlet in the MacVTap agent unassigned RFEs: * https://bugs.launchpad.net/neutron/+bug/2100770 [RFE] Make alembic_migration scripts in neutron idempotent * https://bugs.launchpad.net/neutron/+bug/2073254 nova-compute optional wait for vif-plugged in ovn usecase Further triage needed: * https://bugs.launchpad.net/neutron/+bug/2101077 neutron-bgp-agent dies with debug log + json Info requested from reporter on reproduction method * https://bugs.launchpad.net/neutron/+bug/2100752 Severe Packet Loss During Live Migration Due to Premature Route Advertisement in Neutron BGP Dynamic Routing Edit Lajos promised to triage this Cheers, Bence

9 months, 3 weeks

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