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

Re: [ops][api][all] What are we going to do about pastedeploy usage?

by Sean Mooney

On 17/07/2025 13:37, Stephen Finucane wrote: > oslo.service is going through a lot of churn right now as part of the > eventlet migration. We recently noticed that some unrelated WSGI > routing code had been inadvertently deprecated, and moved to > undeprecate this [1]. so honestly while i think we should likely move off that stack to fastapi or flask ectra im not sure we should do this as a community until the eventlet removal goal is completed. the main thing that paste gave that other frameworks didn't at the time was the ability to configure middleware pipeline via a simple declarative file. > In the long-term, however, this code doesn't > really belong in oslo.service and should be moved elsewhere. I took a > stab at bootstrapping an oslo.wsgi package, and after some hacking I > arrived at a dependencies list containing the following: > > * Paste [2] > * PasteDeploy [3] > * Routes [4] > * WebOb [5] long term i think we could consider all of those to be tech debt that we want to move off of right. we discussed this briefly int eh context of the eventlet removal 18 month ago as you noted but that is likely not the tech stack we want an oslo.wsgi to use long term. > > As some of you might know, all of these packages are minimally > maintained bordering on unmaintained. I'm not entirely sure we want to > want to bootstrap a new project using these libraries as opposed to > migrating off of them. exactly this. > My question is this: how important is the > pastedeploy framework and the paste.ini files nowadays, particularly > for deployers? i would be very interested to see ops feedback here too as that ignoring time for a moment is the only gap i personally see with moving to a better maintained project like fastapi or flask for nova at least. flask is already used by keystone and neutron i think. if i had time i would also like to move watcher off of its current PasteDeploy + pecan + WebOb + WSME stack to fastapi or flask pecan had a long period of inactivity. now it has picked back up in 2025 so its not in a bad place but WebOb, WSME and PasteDeploy is defintly tech debt. > While their use is relatively consistent across projects > (see below), not every service uses them and for those that don't, I > personally haven't heard complaints about their absence. Rather than > migrating the pastedeploy stuff elsewhere, would it make more sense for > affected projects to simply define a static set of middleware (with > some config knobs for those we want to be able to enable/disable) and > call it a day? +1 my inclination was to just have a comma separate list of middle-ware to run in order as part of the standard service config. default to what is enabled in paste today. if need provide a way to load extra middle-ware using https://opendev.org/openstack/stevedore the same way we do plugins in the rest of openstack. > > Cheers, > Stephen > > PS: This topic came up about 18 months ago [6], but we don't appear to > have reached a conclusion. Thus my bringing it up again. > > [1] https://review.opendev.org/c/openstack/oslo.service/+/954055 I'm glad you spotted this as yes only the eventlet web-sever part was intended to be deprecated. > [2] https://pypi.org/project/Paste/#history > [3] https://pypi.org/project/PasteDeploy/#history > [4] https://pypi.org/project/Routes/#history > [5] https://pypi.org/project/WebOb/#history > [6] https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack… > > --- > > fwict, the following services all rely on this combo to build their own > frameworks, with Nova most likely the progenitor in each case (I'm > guessing) > > * Nova > * Barbican > * Cinder > * Designate > * Freezer > * Glance > * Heat > * Manila > * Monasca > * Neutron > * Swift > * Trove > * Vitrage > * Watcher > > The following services do *not* use these libraries: > > * Cyborg (pecan) > * Ironic (pecan) > * Keystone (Flask + Flask-RESTful, with some webob) > * Magnum (pecan) > * Masakari (homegrown framework using webob) > * Zaqar (falcon) > * Zun (Flask) >

5 months, 2 weeks

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

by Goutham Pacha Ravi

Hello Stackers, The Virtual Project Team Gathering (PTG) is next week [1][2]. There are 32 discussion tracks planned throughout the week, along with ad-hoc virtual hallway/water cooler discussions. As a result, many regular weekly IRC meetings will be canceled. Please take a moment to review the PTG Etherpad for the Technical Committee [3]. We encourage community-wide participation on topics such as: - Community Leaders Meeting (2024-10-21 / 1400 UTC): This event is open to all project maintainers, especially PTLs and DPLs. We'll cover several topics of community-wide importance. - Eventlet Removal (2024-10-21 / 1500 UTC): This session will kick off discussions around addressing the technical debt associated with OpenStack services migrating away from the eventlet library. - ...and many more! There may be some minor changes to the schedule based on other cross-project topics being planned. The best way to stay up-to-date is to join OFTC's #openinfra-events channel or watch the event stream on the PTG website [2]. This week, Indiana University will be hosting the OpenInfra community for OpenInfra Days, North America (15-16 Oct 2024). This is a hybrid event, and both in-person and online registrations are still open. If you're attending in person, I’d love to catch up and discuss how the OpenStack TC can assist you. Please don’t hesitate to say hello! === Weekly Meeting === The OpenStack Technical Committee held its weekly meeting on 2024-10-08 [5]. The meeting was well attended. During the meeting, we approved a change to mark the "kuryr-kubernetes" and "kuryr-tempest-plugin" projects as "inactive." This means we won’t be producing any releases from these projects during the 2025.1 "Epoxy" release cycle, and the repositories may soon be retired. If you depend on these projects, please let us know. It’s worth noting that there have been no releases since the 2024.1 "Caracal" cycle. The TC also spent time brainstorming PTG topics and scheduling. We discussed a regression in python-openstackclient that necessitates an update to the recently released 2024.2 "Dalmatian" release. We took action to strengthen the CI jobs for python-openstackclient, adding more scenarios such as upgrade testing with "trunk." The next weekly IRC meeting of the OpenStack Technical Committee is on 2024-10-15, chaired by Dmitriy Rabotyagov (noonedeadpunk). The agenda is available on the meeting wiki page [6]. I hope you can join us. Please remember that you can propose topics by editing the wiki page, and if you do, please include your IRC nick so we can call on you during the meeting. === Governance Proposals === ==== Merged ==== - Mark kuryr-kubernetes and kuryr-tempest-plugin inactive: https://review.opendev.org/c/openstack/governance/+/929698 ==== Open for Review ==== - Propose to select the eventlet-removal community goal: https://review.opendev.org/c/openstack/governance/+/931254 - Propose a pop-up team for eventlet-removal: https://review.opendev.org/c/openstack/governance/+/931978 - Adding Axel Vanzaghi as PTL for Mistral: https://review.opendev.org/c/openstack/governance/+/927962 === How to Contact the TC === You can reach the TC in several ways: 1. Email: Send an email with the tag [tc] on this mailing list. 2. Ping us using the 'tc-members' keyword on the #openstack-tc IRC channel. 3. Join us at our weekly meeting: The Technical Committee meets every Tuesday at 1800 UTC [6]. --- === Upcoming Events === - 2024-10-15: OpenInfra Days NA, Indianapolis [4] - 2024-10-21: OpenInfra Project Teams Gathering: https://openinfra.dev/ptg/ Thank you for reading! On behalf of the OpenStack TC, Goutham Pacha Ravi (gouthamr) OpenStack TC Chair [1] 2025.1 "Epoxy" Release Schedule: https://releases.openstack.org/epoxy/schedule.html [2] "Epoxy" PTG Schedule: https://ptg.opendev.org/ptg.html [3] OpenStack TC PTG Etherpad: https://etherpad.opendev.org/p/oct2024-ptg-os-tc [4] OpenInfra Days North America: https://ittraining.iu.edu/explore-topics/titles/oid-iu/ [5] TC Meeting IRC Log, 2024-10-08: https://meetings.opendev.org/meetings/tc/2024/tc.2024-10-08-18.00.log.html [6] TC Meeting Agenda, 2024-10-15: https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Next_Meeting

1 year, 2 months

[watcher] Call for maintainers - MAAS integration

by Douglas Viroel

Hi everyone, At the last watcher's weekly meeting[1], the team discussed the impacts of the eventlet removal in Watcher's code, and it was brought up that the integration with MAAS (Metal As a Service) support is affected. At the moment, we do not have any active members in Watcher that have any experience with MAAS. CI also doesn't have any job running and testing this integration, and we don't have documentation of how it works. This is a call for maintainers interested in supporting MAAS in Watcher to help fill these gaps. It is worth mentioning that, as discussed in the PTG[2], we also plan to mark this integration as *experimental* once it does not provide minimal testing and documentation (this is also the case of other integrations). But we will cover this topic in a different thread. [1] https://meetings.opendev.org/meetings/watcher/2025/watcher.2025-05-15-12.01… [2] https://etherpad.opendev.org/p/apr2025-ptg-watcher#L71 Thanks and regards, -- Douglas Viroel - dviroel

7 months, 1 week

[glance] Epoxy PTG summary

by Abhishek Kekane

Hi Team, We had our Epoxy virtual PTG between 21st to 25th October 2024. Thanks to everyone who joined the virtual PTG sessions. Using gmeet we had lots of discussion around different topics for glance, glance + cinder, eventlet removal etc. You can find the topics discussed in etherpad [1] with Notes from the session and which also includes the recordings of each discussion. Here I am going to highlight a few important topics which we are going to target this cycle. # Property protection Access to extra properties through Glance’s public API calls may be restricted to certain sets of users, using a property protections configuration file. It can be either role based protection or policy based protection. During this session we have decided to conduct a survey to verify who is using this feature, whether they are using role based or policy based protection. Can we remove either of the protection and do the refactoring? If not then glance will update the documentation for property protection to include reserved properties. Recording: https://drive.google.com/file/d/1WrhkM2dVk6E8KQVDJCt1Bc2aaHi-txGJ/view?usp=… # Periodic job for cache-cleaner and cache-pruner At the moment we have command line utilities to perform these jobs which need to be configured as cron jobs. If we move this under service as a periodic job we can eliminate maintenance of these command line tools and avoid external configuration processes. In this session we decided to introduce two new admin only API calls which will help to clean the cached images. This will help to have an easier deployment process. Recording: https://drive.google.com/file/d/1pmYmVD72zl97gdXRWegYZskDvP50wi6E/view?usp=… # New API to list cached images on all glance nodes As we now have a centralized database as one of the cache drivers, we can now have an api to list images cached on different nodes to give end user overall view of the cache. The actual plan was to list all images cached across the nodes but during the session we found that it is better to get a picture of a single image cached on the nodes. Here we will add a new API call (admin only?) which will accept image id as an input and return the node details where the said image is cached. Recording: https://drive.google.com/file/d/1fv0tBEWbtHcKKfMVLVwc8lPHwN5OM3uh/view?usp=… # Distributed image download if filesystem is enabled We already use distributed imports to avoid configuring shared staging areas across glance nodes, similarly we can use this mechanism to download the image if the filesystem driver is used and the operator wants to avoid configuring shared filesystem in case we have more than one glance node. We have decided to introduce a new configuration option `distributed_download_strategy` with options `None,proxy,redirect`. If it is None then we will return a 404 File Not Found error to the user. If it is a proxy then we will proxy the request to the node where image data is actually present. If it is redirect then we will return a fully accessible image url to the user which he can use to issue a new download request. Recording: https://drive.google.com/file/d/1W5mwifcEfne5HJfNRJ84EyuYGc7NCDJK/view?usp=… # Remove deprecated features/options * sqlite cache driver - Remove in F cycle * Glance scrubber - Remove in Epoxy * Windows support - Sync with gmann to check whether we should remove it now or follow deprecation process of 2 cycles * glance-cache-prefetcher, glance-cache-cleaner, glance-cache-pruner - Deprecate these in Epoxy and remove those in G cycle Recording: https://drive.google.com/file/d/1DFmpy6JRIZw9OTPaw19FD4bW7SR36iNF/view?usp=… # Deprecating python-glanceclient We need to merge pending patches in OSC on priority basis. We will be announcing the deprecation of glance client on openstack mailing list which will help stakeholders to plan OSC migration in next two cycles. Plan is to deprecate the shell in Epoxy with a deprecation warning to each command and then remove the glance client in G cycle. Recording: https://drive.google.com/file/d/1gL6oEpoRL1igjervLFLkNE6eHVWJp3A2/view?usp=… # Horizon Feature Gaps - Cross project session with Horizon team Horizon team is stepping up to provide user interface for new features introduced in glance. You can find the details about it in etherpad [2]. Glance team will help them to migrate from glance-client to OSC and verify and review new user interface. Recording: https://drive.google.com/file/d/12AeTnaQytUhG_tHWN06G78kFYg2YuSGl/view?usp=… # S3 support In this session we have discussed the feature gaps in S3 and other backends of glance. Plan is to find out how we can configure S3 store using swift or ceph and then add a CI job upstream to find out if there are any failures in current supported features. Recording: https://drive.google.com/file/d/1MKEGh7qR9HgCnlhsa4MDjH6Rpl0OaUXe/view?usp=… # Add Glance as first-line defense for image format attacks Here we want glance to act as primary defender for any kind of security vulnerability. You can find the initial idea about it in glance spec [3]. In this session we discussed; * adding new disk-format `gpt` * leaves raw as unstructured data which will be rejected by nova to boot from it. * Migration of existing images from raw to gpt * LUKS inspector (see image encryption session for more details) * Impact on image conversion plugin if gpt disk-format is added Recording: https://drive.google.com/file/d/1xWM7IMCuZ_UenlMUd_rh1KmeuLY6bzSS/view?usp=… # Image Encryption(cross project session with cinder and nova) Here we have discussed the changes in current proposed design with CVE-2024-32498 and how to inspect an image if it is encrypted. Plan is to re-propose the spec with current changes like; * Keep the qcow format as it is and discover the encrypted qcow through metadata (encryption_key_id) * Introduce LUKS as new disk-format Recording: To be updated* # New Location APIs Adoption in Nova and Cinder As Image encryption cross project session took much of the time, we have decided to discuss this topic in the following weekly meeting. Plan is to make nova and cinder use this new location API call so that we can get rid of split deployment (glance internal vs glance external) in this cycle. # Eventlet removal It is a community goal to remove eventlet from OpenStack by 2027.2 (see https://governance.openstack.org/tc/goals/proposed/remove-eventlet.html) Eventlet is causing issues with every new CPython release (at the time of writing, tests are hanging on CPython 3.13). This is a SLURP release so we cannot have "big" changes, but: * we can get "easy" fixes out of the way * we should start working on this so we can merge patches right at the start of the F cycle Glance planning for eventlet removal: * WSGI server Make sure all jobs are running on uwsgi Deprecate/disable the wsgi eventlet server Remove it in 3/4 cycles * Plan for epoxy cycle Deprecate eventlet/wsgi related config option Devstack to by default configure uwsgi Migrate jobs to use uwsgi Migrate from eventlet threadpool to native or io thread pool * Plan for F cycle Fix any issues if occurs for uwsgi * Plan for G cycle Remove wsgi functionality Recording: https://drive.google.com/file/d/1J5nYOCwp2MrrFZAIIvg1YGH4UnaVpk6s/view?usp=… Apart from above topics you can find other miscellaneous topics discussed in PTG etherpad [1]. If you have any questions/suggestions then please join us in our weekly meeting (each Thursday #openstack-meeting irc channel at 1400 UTC). *PS: Since Image encryption was a cross-project session with cinder and nova, once cinder publishes recordings I will update it here on thread. [1] https://etherpad.opendev.org/p/oct2024-ptg-glance [2] https://etherpad.opendev.org/p/horizon-feature-gap [3] https://review.opendev.org/c/openstack/glance-specs/+/925111 Thanks and Regards, Abhishek Kekane

1 year, 2 months

[tacker][ptg] 2026.1 Gazpacho PTG summary

by Yasufumi Ogawa

Hi all, I'd like to share a brief summary of Tacker vPTG. Please refer to our etherpad [1] for whole the duscussion. [1] https://etherpad.opendev.org/p/oct2025-ptg-tacker ## Enhancing Tacker Testing Coverage in the OpenStack Helm Check Pipeline - It's a recap from the previous cycle. To expand the test coverage, improve Tacker testing within the OpenStack Helm (OSH) pipeline by adding more test cases. - Use the OpenStack CLI for Tacker testing, ensuring that no modifications to the OSH test code will be needed even if Tacker's functional tests change. ## Tosca-parser 2.13.0 Validation Failures – Tacker Handling Strategy for Specification Gaps in ETSI SOL001 v2.6.1 - Address the validation failures in tosca-parser happened after it's updated to v2.13.0. - Some VNFDs in tacker's repo are still old and invalid for the stricter validations, but required to be not changed for keeping compatibility with ETSI std version v2.6.1. - We introduced temporary fix just for passing the tests as a remedy, but haven't conclude our policy how we keep the compatibility. As the result, current tacker impl isn't fully compatible with ETSI std. - Continue the discussion for the policy while adding a note for describing the current status of the issue on docs. ## Approach to Prevent Broken Reference URLs in Tacker Documentation - For better maintenance, introduce a periodic job for detecting invalid links. ## Proposal for New Compliance Testcase Implementation for ETSI TST010 Release 3 - Implement new ETSI TST010 Release 3 (v3.3.1) testcases to continue alignment with the ETSI std and strengthen its compliance verification capabilities for VNFM APIs. ## Enabling VNF Support in Prometheus Plugin for Fault Management - Extend Tacker's Prometheus Plugin to enable Fault Management support for VNFs which suppports only CNFs. ## Fix VNF-Package Multi-tenancy issues - Enable multi-tenancy support in VNF Package management by changing the uniqueness scope of vnfd_id from global to per-project. - Due to the current NFV does not support VNF level multi-tenant and it might be a gap between ETSI std, continue to discuss how we fill the gap, for example, making a feedback for multi-tenancy usecase or so. ## Confirm support versions for k8s/Helm/Prometheus on Tacker Gazpacho - The current support versions of k8s/Helm/Prometheus aren't the latest since we've had a failure of updating patch and cannot be fixed yet. - Fix the issue and update to the latest. ## Eventlet removal (Community goal) - Tacker depends on eventlet and need to be modified for the removal. - NEC will discuss if we can proceed with this work. ## Bug triage - Revise Bug maintenance on launchpad for closing too old bugs labeled as critical but can be discarded anymore or so. - Go through the bug list and give comments about their related bugs Thanks, Yasufumi

1 month, 3 weeks

[nova][elections][ptl] Application for the PTL role 2026.1

by René Ribaud

Hello, I am announcing my new candidacy for the PTL role for Nova and Placement. Serving as PTL in the Flamingo cycle was both a rewarding and instructive experience. It allowed me to learn the responsibilities and workload of the role, build stronger connections across the community, and help contributors move their work forward. In the next cycle, I want to continue fostering a welcoming and collaborative environment for all contributors. I will continue and improve our efforts to enhance bug triage, reduce the number of open bugs, and support timely reviews to help features progress toward completion. I am also eager to follow and participate in the Eventlet removal effort, which began in Flamingo and represents a major step for OpenStack. This is a particularly interesting challenge—not highly visible to most users, but crucial for the long-term health, performance, and maintainability of the project. My main focus, and the most important thing to me, will remain ensuring that Nova and Placement stay robust, maintainable, and aligned with our users’ needs. Thank you for your trust so far, I’d be happy to continue serving in this role. Thanks, René

4 months, 2 weeks

[cinder][PTG] 2025.2 Flamingo PTG summary

by Jon Bernard

Hello everyone, thanks for a very productive PTG for the Flamingo cycle. Below is a brief summary of the highlights. The raw etherpad notes are here [1] and both the summary and transcribed etherpad notes are captured in out wiki here [2]. # Eventlet Removal This cycle we will try complete the removal of Eventlet from our codebase. We dicussed our current usage, including calls to sleep() and tpool.Proxy(). We agreed to split the work between Eric and me. I hope we can get these patches up and reviewed with time to spare before the release. An idea to revive our fake volume driver was raised to potentially gain greater confidence in high concurrency test configurations. # Testing Volume Replication Although volume replication is support by a few of our in-tree drivers, there are no integration tests that verify correct behaviour in tempest. Discussions on adding tempest tests lead to Liron being interested in driving this effort. Changes will need to be made to devstack-ceph plugin to support deploying multiple ceph clusters, as well as gate configuration to run all of this in a multi-node environment. There are a few important moving pieces which may take some time to sort out, but we agreed to commit to working towards a solution in this cycle. # Follow-up from Epoxy We have a few patch series that we didn't have time to review by the deadline of the Epoxy cycle. Volume type metadata, encryption format, and dm-clone just to name a few. Effort in reviewing and gathering feedback needs to be prioritized in the first half of the cycle to make sure we can confidently land these in Flamingo. # CI status We should review our 3rd party CI instances to make sure they're actually running, running the correct tests in the context of the related change, and reporting results that can be viewed by a gerrit reviewer. It was noted that some of them fall short of some or all of these requirements. It would be helpful to gather a current status so that we can help vendors with awareness. # 2023.2 Final Stable Release On April 30, the stable/2023.2 branch will have it's final release. This will mark the end of cinderlib. We still have a few backports that need reviews currently, see etherpad for details. # Backup Improvements crohmann raised 2 patches that both improve the speed of cinder-backup's startup routine, and decouple a volume's backup status from it's overall status. Eric and Brian agreed to review to help move these patches forward. # RBD Geometry Option We've have an old patch to allow RBD's disk geometry to be configurable. This reportedly improves performance of Windows guests significantly. We agreed to make sure this gets reviewed in this cycle. # Stephen's Patches We have 3 patches carried over from last cycle that need review. These include an OpenAPI series, a patch to map block storage AZs to Compute AZs, and updates to OSC. It would be really nice to get these reviewed in this cycle. # Tobias' Patches We have several patches from Tobias all related to cinder-backup improvements. Including adding support for backup service to os-availability-zone, support for filters in query parameters, the addition of a summary API, and potentially adding a `type` field to the API to open the posibility of support backups types beyond just `full` or `incremental`. [1] https://etherpad.opendev.org/p/apr2025-ptg-cinder [2] https://wiki.openstack.org/wiki/CinderFlamingoPTGSummary -- Jon

8 months, 2 weeks

[PTG] Call for Summaries, Attendance Numbers, and Team Photos

by Kendall Nelson

Hello Folks! I am working on a summary post for our OpenInfra Blog as usual and I am missing A LOT of attendance numbers from OpenStack teams. Specifically, I am missing attendance numbers from: - Barbican - Blazar - Cinder - Cloudkitty - Cross Deploy - Designate - Eventlet Removal - Glance - Heat - Horizon - i18n - Ironic - Keystone - Kolla - Magnum - Neutron - OpenStack Ansible - OpenStack Helm - Sunbeam - Swift - Tacker - Telemetry - Watcher If you were a moderator for this session please send me your approximate attendance to ptg(a)openinfra.org ASAP. If you simply attended one of these sessions, and you would be so kind as to remind the moderator to send me the info I would be very grateful! Additionally, I will happily accept any team photos that were taken and links to blog posts or other summaries that I can include in OpenInfra Blog post as well. There are a lot of open source communities outside of the OpenInfra Foundation that are curious about how we conduct our PTGs and these posts are incredibly helpful at educating others on how to follow the four opens and build a stronger community. Thank you for all of your support! Looking forward to the next PTG! -Kendall

1 month, 4 weeks

PTG April 2025 Teams List

by Kendall Nelson

Hello Everyone! The list of teams participating in the upcoming virtual PTG (April 7-11, 2025) is now official! Projects + Teams - OpenInfra Foundation Teams - - OpenInfra Diversity and Inclusion Working Group - Kata Containers - OpenStack - - Services - - Blazar - Cinder - CloudKitty - Designate - Glance - Heat - Horizon - Ironic - Keystone - Kolla - Manila - Neutron - Nova - Octavia - OpenStack-Ansible - OpenStack SDK/CLI - Sunbeam - Swift - Tacker - Watcher - Other OpenStack Teams - Eventlet Removal - i18n SIG - OpenStack for AI Working Group - OpenStack Security SIG - OpenStack Technical Committee - Public Cloud SIG - VMware Migration Working Group - StarlingX - Adjacent Open Source Communities - - OceanBase If your team was planning to meet and isn’t in this list, please contact ptg(a)openinfra.dev IMMEDIATELY. Soon I will be contacting moderators to sign up for time via the PTGBot[1] once it is configured for the teams that are signed up to attend the event. Etherpads for agenda planning and note taking will be automatically generated as a part of that configuration. Otherwise, please don't forget to register[2] — it's FREE! Also, it does help us with event coordination and communication, so please take a moment to register. As usual, feel free to let me know if you have any questions! Thanks! -Kendall (diablo_rojo) [1] PTGBot Docs: https://opendev.org/openstack/ptgbot#open-infrastructure-ptg-bot [2] PTG Registration: http://ptg.openinfra.org/

9 months, 4 weeks

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

by Sean Mooney

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

6 months, 2 weeks

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