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

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

by Herve Beraud

Le mer. 30 oct. 2024 à 13:05, Stephen Finucane <stephenfin(a)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> 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/

1 year, 2 months

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

by Goutham Pacha Ravi

On Mon, Jun 23, 2025 at 3:50 PM Goutham Pacha Ravi <gouthampravi(a)gmail.com> wrote: > > Hello Stackers, > > We're fourteen weeks away from the coordinated 2025.2 "Flamingo" > release of OpenStack [1], and Milestone-2 for this release is on > 2025-07-03. In the past week, the Call for Papers for the upcoming > OpenInfra Summit in Paris-Saclay ended; however, the deadline to > propose Forum sessions and Project Updates sessions is 2025-07-08 at > 23:59 PST [2]. This time at the summit, there's also a "New > Contributor Showcase" inviting presentations on projects that leverage > or support open infrastructure. Whether it’s your first contribution, > an open source tool, or a collaboration with a community, we want to > hear about it, so please consider applying [3]. > > In the past week, the OpenStack Technical Committee did not merge any > new governance changes. A few change proposals are open for the > community's input. OpenDev Infra administrators and OpenStack's > Release Management team have posted several changes to begin enforcing > the Developer Certificate of Origin in lieu of the Contributor License > Agreement from July 1, 2025 [4]. If you haven't already begun using > "git commit -s" to sign off your commits in adherence to the DCO, > please do so. As a reminder, from July 1st, OpenDev's Gerrit system > (https://review.opendev.org) will reject any changes that do not > include a "Signed-off-by" line in the commit message. Simultaneously, > the existing CLAs will no longer be available for new contributors to > sign. > > === Weekly Meeting === > > The OpenStack Technical Committee met on OFTC's #openstack-tc channel > on 2025-06-17 [5]. The team confirmed plans to transition to DCO > (Developer Certificate of Origin) by July 1st, approving updates to > the contributor guide and discussing the ongoing process of > integrating DCO across tools and translations. We then focused on > improving the contributor experience, with analyses of review metrics > being shared with various project teams like Nova and Cinder through > weekly IRC meetings. This data collection aims to identify pain points > and best practices to inform future strategies. We plan to drive > collective attention to this effort during the PTG in October. > > We also discussed the level of activity in the Cyborg project. We have > had issues contacting the core maintainers to get some critical fixes > merged, and the TC agreed to begin the process to mark the project > "inactive." This decision aligns with the upcoming M-2 release > deadline. The discussion also prompted a health check on several > project teams. We'll be discussing this in further detail on proposals > directly on Gerrit, or in a future weekly meeting. > > OpenDev Infra administrators completed a transition from Nodepool to > Zuul-launcher and pleasantly have not seen any negative impact on the > CI. During an Open Discussion, concerns were raised about the timeline > specified by the Eventlet Removal TC goal [6]. Nova maintainers, in > particular, expressed the need for more time to ensure a stable > transition to threading and adequate operator testing, suggesting a > revised target of 2028.1 for full Eventlet removal, a point that will > be further debated on the mailing list [7] and a Gerrit proposal [8]. > > The next meeting of the OpenStack Technical Committee is on > 2025-06-24. It will be hosted over IRC in OFTC's #openstack-tc channel > at 1700 UTC. Please find the agenda and other details on the meeting's > wiki page [9]. I hope you'll be able to join us. > > === Governance Proposals === > > ==== Open for review ==== > > - Require declaration of affiliation from TC Candidates | > https://review.opendev.org/c/openstack/governance/+/949432 > - Make Eventlet removal deadlines more acceptable for operators | > https://review.opendev.org/c/openstack/governance/+/952903 > - Mark Cyborg inactive | > https://review.opendev.org/c/openstack/governance/+/952798 > > === Upcoming Events === > > - 2025-06-28: OpenInfra+Cloud Native Day, Vietnam: > https://www.vietopeninfra.org/void2025 > - 2025-07-03: OpenStack's 15th Birthday, Colombia User Group: > https://www.meetup.com/colombia-openinfra-user-group/events/308383244 > - 2025-07-08: OpenInfra Board meeting: https://board.openinfra.org/ > - 2025-07-19: OpenInfra Days, Indonesia: https://2025.openinfra.id/ > > Thank you very much for reading! > > On behalf of the OpenStack TC, > Goutham Pacha Ravi (gouthamr) > OpenStack TC Chair (sigh, here are the references:) [1] 2025.2 "Flamingo" Release Schedule: https://releases.openstack.org/flamingo/schedule.html [2] OpenInfra Summit CFP for Forum and Project Updates: https://summit2025.openinfra.org/cfp/ [3] New Contributor Showcase @ OpenInfra Summit: https://summit2025.openinfra.org/new-contributors-at-the-openinfra-summit/ [4] OpenStack requires DCO: https://governance.openstack.org/tc/resolutions/20250520-replace-the-cla-wi… [5] TC Meeting IRC Log 2025-06-17: https://meetings.opendev.org/meetings/tc/2025//tc.2025-06-17-17.00.html [6] TC Goal to replace Eventlet in OpenStack: https://governance.openstack.org/tc/goals/selected/remove-eventlet.html [7] Eventlet timeline on openstack-discuss: https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack… [8] Eventlet timeline: Make Eventlet removal deadlines more acceptable for operators | https://review.opendev.org/c/openstack/governance/+/952903 [9] TC Meeting Agenda, 2025-06-24: https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Next_Meeting

6 months, 1 week

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

by Herve Beraud

Thanks Sean for clarifications. Le mar. 17 juin 2025 à 20:22, Sean Mooney <smooney(a)redhat.com> a écrit : > > On 17/06/2025 18:52, Herve Beraud wrote: > > I think there is an option C. > > > > Since the beginning of this initiative, the goal has always been to > > phase out Eventlet cleanly from OpenStack components, particularly > > Nova. The initial proposal targeted the 2027.2 release, at a time when > > Nova had no plans to support a dual concurrency model. At that point, > > Eventlet removal was not classified as a feature removal subject to > > SLURP policy - it was considered an internal refactoring, with no > > addition of transitional features requiring later removal. The idea > > was to deprecate any Eventlet-related features, public APIs, and > > configuration options as early as possible. As a result, SLURP policy > > constraints were not a primary concern. > > > > But the situation has evolved. Nova has now committed to offering a > > full release cycle (2027.1) where both concurrency models - Eventlet > > and threading - are supported. This is not a technical convenience, > > but a response to explicit operator requests: operators want the > > ability to switch concurrency modes outside in case of problem during > > at least one series. The full threading support in Nova will not be > > ready before 2026.2, which is a non-SLURP release, and that the > > dual-mode support must be preserved throughout 2027.1. > > unless this has changed since the ptg we were hoping for the first > release to supprot runign without eventlet to be 2026.1 and the defautl > to chagne in 2026.2. > > so 2026.1 would be the slrup release where operator woudl chage to > eventlet before upgrading to 2027.1 > > > > > However, current SLURP policy requires that a removal can only happen > > in a SLURP release. > That is incorrect. deprecation can only happen in slurps removals can > happen in either provided the feature is deprecated in the prior slurp. > > According to Nova's plan that excludes a removal in 2027.1. > > that is also incorrect removal is only exclded if we dont get to full > threadign supprot in 2026.1 we have not deprecated evenlet supprot > > yet and we dont plan do do that formally until we have show that nova > can work without it. > > > If we follow the rules strictly, Eventlet removal would be delayed to > > 2028.1, adding several months of dual-mode support, increased > > maintenance complexity, and growing technical debt. > again this is very much misrepresenting the current plan. > > > > From a technical standpoint, it’s important to highlight that upcoming > > Python versions (3.14 and 3.15) introduce major changes to the GIL > > [1], threading behavior, and RLocks - all areas [2] that have > > historically been problematic in Eventlet. We’ve already had to > > implement significant patches for Python 3.13. There is also > > uncertainty around which Python versions will be adopted by the > > various Linux distributions and by our own supported runtime > > environments, making long-term compatibility assumptions with Eventlet > > increasingly risky, but in all the cases it will put additional > > pressure on us. Continuing to support Eventlet until 2028 is > > effectively betting on the stability of a module that is already on > > life support, with very few contributors available to maintain it > > beyond 2027 (see Jay's note about GR-OSS). More critically, there is > > no guarantee today that Eventlet, in its current state, will remain > > robust enough to reliably support a fallback path in case a regression > > forces a rollback from threading to Eventlet. > > > > This is why I propose a pragmatic and balanced compromise: we maintain > > the planned deprecation (we might have to adjust a little bit those > > from oslo), but we make a documented and limited exception to allow > > Eventlet removal in 2027.2, which is a non-SLURP cycle. This exception > > would be coordinated with the Technical Committee and the release team > > and is justified by: > > > > - the commitment made by Nova to offer a full cycle of dual-mode > > support in 2027.1; > > again that was not what we commited too. we aim to provide that in > 2026.1 if we dont make that > > teh deprecation fo eventlet supprot will slip to 2026.2 and we will > supprot both in 2027.1 and do the removal in 2027.2. > > supprot for eventlet in 2027.1 is predicated in not completeing the work > in 2026.1. > > > - the high technical cost of maintaining dual concurrency models; > > - the fast evolution of Python and the increasing risk of > > incompatibilities with Eventlet; > > - the limited engineering resources available to sustain Eventlet > > maintenance; > > - and the need to align with operator expectations while still > > securing the long-term health of the platform. > > > > This approach gives Nova the entire 2027.1 cycle to deliver a complete > > and stable dual-mode implementation, as promised to operators. At the > > same time, it enables the rest of the ecosystem to move forward > > safely, without relying on a dependency that is increasingly brittle > > and obsolete. > > > > In large open source projects, it is not uncommon for policies to be > > temporarily adjusted in the face of structural or technical > > emergencies. This is not a convenience exception - it’s a reasoned and > > responsible deviation from the norm, driven by necessity. > > > > For this reason I add the release team and the TC to the party. Please > > share your feedback with us. > > > > [1] > > > https://docs.python.org/es/dev/whatsnew/3.14.html#whatsnew314-free-threaded… > > [2] https://docs.python.org/es/dev/whatsnew/3.15.html#threading. > > > > Le lun. 16 juin 2025 à 18:06, Sean Mooney <smooney(a)redhat.com> a écrit : > > > > > > On 16/06/2025 15:33, Dmitriy Rabotyagov wrote: > > > Also let's keep in mind, that only nova (with placement) will > > spawn 64 > > > threads on such setup by default. > > > > yep see my other reply. > > > > you mixign up workers and eventlet threads. > > > > those are two very diffent things. > > > > we likely shoudl change the upstream default for workers to 1. > > > > we do tend to override that by defualt in installer tools. > > > > > > > > And then all really depends on set of services to launch on such > > setup. > > > > > > So from deployment tooling protective you have all required data to > > > rollout not instantly oom-ing setup at cost of amount of request > > > services can process in parallel. > > > > > > On Mon, 16 Jun 2025, 15:24 Dmitriy Rabotyagov, > > > <noonedeadpunk(a)gmail.com> wrote: > > > > > > In case you try to use a 32gb box with 16 cores as a controller > > > for OpenStack - it will blow off with default amount of workers > > > for wsgi and /or eventlet apps. > > > > > > While you can argue this should not be used as production > setup, > > > this can be totally valid for sandboxes and we wanna provide > > > consistent and reliable behavior for users. > > > > > > But my argument was not in if/how we want to fine-tune > > > deployments, but also understand and provide means to define > > > what's needed as well as potential ability to revert in > > worst case > > > scenario as a temporary workaround. > > > So still some variables and logic would be introduced from > > what I > > > understand today. > > > > > > > > > On Mon, 16 Jun 2025, 14:43 Sean Mooney, <smooney(a)redhat.com> > > wrote: > > > > > > > > > On 16/06/2025 13:27, Dmitriy Rabotyagov wrote: > > > > > > > > > > > > > > > > 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 > > > > > > > > > > > > Well, we'd need to have that communicated so that > > deployment > > > toolings > > > > could adopt their setup to changes, as, for instance, > > in OSA > > > amount of > > > > eventlet workers are calculated based on the system > facts, > > > so we'd > > > > need to change the logic and also suggest how users > should > > > treat this > > > > new logic for their systems. > > > > > > why is OSA doing that at all today? > > > we generally don't recommend changing those values from the > > > default > > > unless you really know what your doing. > > > i don't think other installer do that. > > > tripleo, kolla-ansbile and our new golang based installer > do > > > not, nor > > > does devstack so its surprising to me that OSA would change > > > such low > > > level values > > > by default. > > > > > > we will document any new config options we and and we are > > > documentation > > > how to tune the new options for thread pools but we do > > not expect > > > installation > > > tools to modify them by default. we are explicitly not > > making the > > > options based on the amount of resources on the host i.e. > > > dynamically > > > calculated based > > > on the number of CPU cores. > > > > > > for example we are explicitly setting the number of > > > scatter_gather > > > thread in the the dedicated thread pool to 5 > > > why its a nice small number that will work for most > > people out > > > of the box. > > > > > > can you adjust it, yes but it scale based on the number of > > > nova cells > > > you have an 99% wont have more then 5 cells. > > > > > > using information about the host where the API is > > deployed to > > > infer the > > > value of that would be incorrect. > > > > > > you can really only make an informed decision about how to > > > tune that > > > based on monitoring the usage of the pool. > > > > > > that how we expect most of the other tuning options to > > go as well. > > > > > > our defaults in nova tend to be higher then you would > > actually > > > need in a > > > real environment so while it may make sense to reduce > > > them we try to make sure the work out of the box for > > most people. > > > > > > gibi id building up > > > > > > https://review.opendev.org/c/openstack/nova/+/949364/13/doc/source/admin/co… > > > > > > as part of nova move to encode this but our goal is that > > > deployment > > > tools shoudl not need to be modifyed to tune these > > > valued by defualt. > > > > > > > > > > > So it will be kinda documented in a way after all. > > > > > > > > > > > > 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) > > > > > > > > > > > > > > > > > > > > -- > > Hervé Beraud > > Principal Software Engineer at Red Hat > > irc: hberaud > > https://github.com/4383/ > > > > -- Hervé Beraud Principal Software Engineer at Red Hat irc: hberaud https://github.com/4383/

6 months, 2 weeks

Re: Upstream Oslo IRC Meetings Are Back.

by Herve Beraud

Le jeu. 31 oct. 2024 à 18:38, Takashi Kajinami <kajinamit(a)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) 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 release team created tooling to generate this kind of etherpad, perhaps you could reuse it... 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. > 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. It is up to you. [1] https://meetings.opendev.org/#Oslo_Team_Meeting > > On 10/31/24 7:07 PM, dbengt(a)redhat.com wrote: > > > > > > On 10/30/24 5:57 PM, Ghanshyam Mann <gmann(a)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 [2] > https://www.vyte.in/e/2j0to257cd > > > > -- Hervé Beraud Senior Software Engineer at Red Hat irc: hberaud https://github.com/4383/

1 year, 1 month

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

by Goutham Pacha Ravi

Hello Stackers, It's been a quiet-yet-busy week for the OpenStack Technical Committee as we approach the tail end of the 2024.2 (Dalmatian) release cycle [1]. We're 8 weeks away from the release date (2024-10-02) and three weeks away from the feature code freeze across many OpenStack code repositories (2024-08-29). If you are a maintainer of an OpenStack repository with any Zuul jobs, I'd encourage you to check if your repository is flagged with any configuration errors [2]. It's possible you're referencing a nodeset or a code repository that isn't there anymore (for example, CentOS-8-Stream was recently deleted [3]). Or, it's possible that you have deprecated syntax. There's a lot of prior art if you would like to fix your Zuul configuration. If you're unsure what to do, please send an email to this list or chat with a Zuul maintainer on OFTC's #opendev channel. The nomination period for PTL positions and the OpenStack TC begins next week (2024-08-14). Election officials will be sharing more context over the next week. If you are a PTL or a member of the TC, motivate individuals to take on these leadership roles and support their enthusiasm. === Weekly Meeting === The TC had a productive meeting over IRC last week [4]. We discussed phased updates to the eventlet removal proposal [5] and the health of the CI system over the past week. Several contributors helped land CVE fixes in the past couple of weeks, which required bumping up package constraints within older stable branches. The removal of CentOS-8-Stream nodesets and the Linaro arm64 region from Zuul caused some gate instability; the Infrastructure team will be glad to assist anyone who's triaging failures caused by these actions. The TC noted the need to delay the retirement of "kuryr-kubernetes" until the Tacker project team has stopped relying on it. The next meeting is on Tuesday (2024-08-06), and it will be simultaneously hosted on Zoom and IRC. Information to join this meeting and the meeting's agenda are on our Wiki page [6]. I hope you'll be able to join us there. === Governance Proposals === ==== Merged ==== Follow up on the affiliation diversity handling | https://review.opendev.org/c/openstack/governance/+/923876 Add os-test-images under glance | https://review.opendev.org/c/openstack/governance/+/925044 [follow up] Fix typos in the eventlet removal proposal | https://review.opendev.org/c/openstack/governance/+/924944 ==== Open for Review/Discussion ==== Update criteria for inactive projects to become active again | https://review.opendev.org/c/openstack/governance/+/921500 Inactive state extensions: Monasca | https://review.opendev.org/c/openstack/governance/+/923919 === Upcoming Events === 2024-08-06: OpenInfra Board Meeting: https://board.openinfra.dev/meetings/2024-08-06 2024-08-12: Call for Proposals due for the OpenInfra Days NA [8] 2024-08-14: Nominations open for 2025.1 OpenStack PTL+TC elections 2024-08-24: Open Infra Days, Vietnam: https://2024.vietopeninfra.org/ 2024-08-29: Dalmatian-3 milestone 2024-09-03: OpenInfra Summit Asia, Suwon Thank you very much for reading! On behalf of the OpenStack TC, Goutham Pacha Ravi (gouthamr) OpenStack TC Chair [1] Release Schedule: https://releases.openstack.org/dalmatian/schedule.html [2] Zuul Configuration Errors: https://zuul.opendev.org/t/openstack/config-errors [3] CentOS-8-Stream node pool removal: https://lists.opendev.org/archives/list/service-announce@lists.opendev.org/… [4] TC Meeting IRC Logs, 2024-07-30: https://meetings.opendev.org/meetings/tc/2024/tc.2024-07-30-18.00.log.html [5] Remove Eventlet From Openstack: https://review.opendev.org/c/openstack/governance/+/902585 [6] TC Meeting, 2024-08-06: https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Next_Meeting

1 year, 4 months

Re: #eventlet-removal - Progress & Update

by Rodolfo Alonso Hernandez

Hello all: This is a quick update of the status of Neutron and stadium projects in the eventlet deprecation. We have created a topic for next week PTG [1]. During the PTG we'll discuss the deprecation strategy. In order to facilitate the analysis, I've created [2], that is a collaborative document with the relevant code findings related to eventlet. A month ago I sent an update [3] with a list of patches merged, most of them related to issues in the Neutron API eventlet to WSGI migration. Now we have the ML2/OVS jobs migrated and the ML2/OVN are proposed for neutron-tempest-plugin and merged for Neutron: * https://review.opendev.org/c/openstack/neutron/+/923711 * https://review.opendev.org/c/openstack/neutron-tempest-plugin/+/923730 * https://review.opendev.org/c/openstack/neutron/+/924317 * https://review.opendev.org/c/openstack/neutron-tempest-plugin/+/930743 We have also proposed some trivial (but necessary) patches to remove some eventlet methods in the code: * https://review.opendev.org/c/openstack/neutron/+/931249 * https://review.opendev.org/c/openstack/neutron/+/931251 The next steps will be defined in the PTG and made public here and in the PTG summary. Regards. [1]https://etherpad.opendev.org/p/oct2024-ptg-neutron [2]https://etherpad.opendev.org/p/neutron-eventlet-deprecation [3] https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack… On Wed, Oct 9, 2024 at 1:38 PM <smooney(a)redhat.com> wrote: > On Wed, 2024-10-09 at 12:01 +0200, Sylvain Bauza wrote: > > Le ven. 4 oct. 2024 à 17:41, engineer2024 <engineerlinux2024(a)gmail.com> > a > > écrit : > > > > > That's encouraging news. I hope the new alternative would support a > python > > > debugger like pdb. This will help the new users to understand the > > > flow better. So when can we expect initial release atleast beta of > eventlet > > > free nova components ? > > > > > > > > That's an excellent question that I don't have an answer. We started to > > work on it on Dalmatian but for the moment, I don't know whether the > owner > > could continue to work on it on Epoxy or if someone else would do it. > i dont think we will ever have a "beta" release without eventlet > our expection is that we will do a phased removal. > > so the iniall goal was to to tackel some of the low hanging furit in > dalmation > the first part of that was spliting the delivberable in nova that actully > need eventlet > vs those that dont > > i.e. the command line clinets were monkey patched but never needed > eventlet so those > were simple to seprate to remove the monkey patching > thats what https://review.opendev.org/c/openstack/nova/+/904424 does > > the next step is to remove our use of eventlets thread pool and replace it > with futureist's > version. > https://review.opendev.org/c/openstack/nova/+/922497/5 > https://review.opendev.org/c/openstack/nova/+/905287/9 > https://review.opendev.org/c/openstack/nova/+/917962/8 > > the third step is to remove the only usage of eventlet in the nova-api > wsgi module > > https://review.opendev.org/c/openstack/nova/+/905284/7 > > i may or may not have time to work on this in 2025.1 > > i will likely try to make some progress but i may need to hand this off to > someone > else or rope in some other to help. if we can compelte what i had orginally > scoped in > https://blueprints.launchpad.net/nova/+spec/eventlet-removal-part-1 for > 2025.1 > that woudl be a good first step. > > > next steps would be two fold. > first we need to change how spawn core service event loop by using the new > backend being > added by https://review.opendev.org/c/openstack/oslo-specs/+/927503 > > second we need to change how we handel rpc requests. > when the agent recives an rpc instest of executiong the function on the > main thread we > need to dispatch that to either a GreenThreadPoolExecutor when we are > monkey patched (using eventlet) > https://github.com/openstack/futurist/blob/master/futurist/_futures.py#L318 > or a ThreadPoolExecutor > https://github.com/openstack/futurist/blob/master/futurist/_futures.py#L99 > when we are not usign eventlet. > > that is requried so we can still have concurrent interleaved rpc > processing and allow the > threaded version to just block waiting on future as needed. > > that bit i have not figured out exactly where to do that yet. > but factoring out the rpc handling to use the executor interface would > likely be eventlet-removal-part-2 (2025.2) > since that can be done without a dep onthe oslo.service change and then > > eventlet-removal-part-3 2026.1 woudl be converting to the new oslo.servce > backend and any remaining clean up. > > that is optimistic and a lot of work so it may take longer or we might be > able to start some other things earlier. > > tehre is a lot of good work in > https://wiki.openstack.org/wiki/Eventlet-removal#Migration_Plan also. > > nova at present is not planning to use asynio but that does nto mean we > never will > we just dont have a high enough concurrence requireemtn to need it so > trhead pools > shoud be sufficient > > once we are using them there is no reaosn we coudl not have an > AsyncioPoolExecutor > using awaitlet or explore using asyncio more directly > > to your debugger point any servie that is not monkey patched will gain the > ablity to just run > in a debugger normally i.e. once we get rid of using it in the api wsgi > module you should be able to just > debug it but keep in mind that nova is a distributed system os if you set > a breakpoint you will very likly > cause request to time out. debuging a distribute system is not the same as > debuging a application running on > a single host and never will be. > > that is not a goal of this work its just a side benifit. > > > > > -Sylvain > > > > On Fri, 4 Oct 2024, 20:38 Herve Beraud, <hberaud(a)redhat.com> wrote: > > > > > > > We’re excited to share the latest updates on our ongoing efforts to > phase > > > > out Eventlet across our various OpenStack projects. Below you’ll > find a > > > > summary of our progress, key milestones, and important dates to keep > in > > > > mind as we move forward with this critical initiative. > > > > > > > > ## Current Status > > > > > > > > We’ve completed the initial analysis phase across more than 120 > OpenStack > > > > projects. This includes identifying the various patterns where > Eventlet is > > > > currently in use and evaluating where it can be safely removed or > disabled. > > > > Here are some highlights: > > > > > > > > - Completed Analysis: Projects where Eventlet is used include (but > are > > > > not limited to): Aodh, Barbican, Nova, Neutron, Tacker, Taskflow, > Trove, > > > > Venus, Watcher, and Zun. > > > > > > > > - Eventlet Optional: Several projects have been identified where > Eventlet > > > > seems to be optional and can be disabled with minimal impact. For > these > > > > projects, we will move forward the discussion with teams to try > > > > deactivating Eventlet in upcoming updates. Once done, projects of > this kind > > > > would be able to start their migration with more serenity. > > > > > > > > - Eventlet Required: Some projects still rely heavily on Eventlet for > > > > core functionality. For these, we are going to develop specific > migration > > > > plans. > > > > > > > > ## Migration Plans in Progress > > > > > > > > - oslo.db: Preparing its Asyncio based engine facade; > > > > - oslo.service: Refactoring plans being discussed to minimize > disruption > > > > during the migration; > > > > - glance: Refactoring code to use native thread model rather than > Eventlet > > > > > > > > More details can be found here: > > > > https://review.opendev.org/q/topic:%22eventlet-removal%22 > > > > > > > > ## Latest Updates > > > > > > > > - Community Goal Transition: The ongoing community goal for removing > > > > Eventlet is now in the process of becoming an official "selected" > goal, > > > > https://review.opendev.org/c/openstack/governance/+/931254. > > > > > > > > - Pattern Identification Completed: We’ve identified key patterns > related > > > > to Eventlet usage, including its common integration with > monkey_patch(), > > > > eventlet.Timeout, eventlet.GreenPool, and eventlet.wsgi.server(). > Visit the > > > > official wiki to get more details > > > > > https://wiki.openstack.org/wiki/Eventlet-removal#Identifying_Common_Pattern > > > > > > > > ## Important Dates > > > > > > > > - October 21st: cross PTG session. > > > > - October 23rd: cross PTG session (Q&A session and Open Discussion > > > > session) > > > > > > > > ## Call to Action > > > > > > > > We need your involvement to accelerate the progress of this > initiative! > > > > If your project is affected by Eventlet, now is the time to start > planning > > > > your migration. Teams are encouraged to take immediate steps in > assessing > > > > how to deactivate Eventlet or to transition to alternative solutions. > > > > > > > > We defined key roles and responsibilities. Those will help us to > lower > > > > the cost of the migration for our community. Teams are invited to > assign > > > > them now. Being ready as soon as possible will allow you to better > take > > > > advantage of the coming PTG sessions. > > > > > > > > Please find more details about these roles and their short terms > tasks: > > > > > https://wiki.openstack.org/wiki/Eventlet-removal#Roles_and_Responsibilities > > > > > > > > ## Final Thoughts > > > > > > > > This is a significant step forward for improving the stability, > > > > scalability, and maintainability of our projects. With your continued > > > > support, we’re confident that this migration will bring substantial > > > > benefits to the OpenStack community. > > > > > > > > If there are any questions or if you need assistance with your > project’s > > > > transition away from Eventlet, please join the discussion on the > > > > #eventlet-removal channels (OpenStack irc, RedHat slack, mailing > list). > > > > > > > > Thank you for your dedication and hard work! > > > > > > > > -- > > > > Hervé Beraud > > > > Senior Software Engineer at Red Hat > > > > irc: hberaud > > > > https://github.com/4383/ > > > > > > > > > >

1 year, 2 months

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

by Dmitriy Rabotyagov

> > > 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 > Well, we'd need to have that communicated so that deployment toolings could adopt their setup to changes, as, for instance, in OSA amount of eventlet workers are calculated based on the system facts, so we'd need to change the logic and also suggest how users should treat this new logic for their systems. So it will be kinda documented in a way after all. > 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 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? 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> 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/ >

1 year, 2 months

Re: #eventlet-removal [ptg] 2025.2 Flamingo PTG summary

by Herve Beraud

Thanks Thomas for the details about Debian, much appreciated. Concerning the Eventlet releases, fixes, and patches, unfortunately for now I cannot answer your question. As pointed out at the PTG session, the maintenance activity is decreasing due to the lack of resources, so it is difficult to determine what and when to get updates on the upstream repo. My workaround (https://github.com/eventlet/eventlet/pull/1031) is pending for reviews and as you pointed out on IRC days ago this workaround does not seem enough to fix your failures. I think we will have to iterates over several patches to stabilize with Python 3.13. Le ven. 18 avr. 2025 à 10:54, Thomas Goirand <zigo(a)debian.org> a écrit : > Hi, > > On 4/17/25 17:44, Herve Beraud wrote: > > With Ubuntu 2025.4 planning to ship Python 3.13 by default, we're facing > > a hard deadline for this work > > > > https://discourse.ubuntu.com/t/plucky-puffin-release-schedule/36461 > > If I may: Debian 13 (aka: Trixie) is already in (soft) freeze, and > shipping Python 3.13 only also. Harder freeze is in a month, complete > freeze is still not announced yet. I'm also very worried about the state > of Eventlet with Epoxy on Trixie (I haven't had time to tempest test it > yet). > > Is there a new eventlet release that's going to fix more issues? Will > you continue working on the patch you pointed at, and make sure > OpenStack continues to work with it? > > Thanks for all your work on this, > Cheers, > > Thomas Goirand (zigo) > > -- Hervé Beraud Principal Software Engineer at Red Hat irc: hberaud https://github.com/4383/

8 months, 2 weeks

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

6 months, 1 week

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