March 2026 - openstack-discuss - lists.openstack.org

[nova] Live migration of memory-intensive workload in error
by Timothé Baugé 25 Mar '26

25 Mar '26

Hello stackers, I'm reaching out to the community to understand how you manage migrations of memory-intensive instances. We are running RHOSP 17.1 (based on Wallaby) and have faced several issues when live-migrating instances running on compute nodes to do maintenance work. For several memory-intensive instances, the process just never completes properly and ends in error after hours waiting. During the migration, we can see in nova-computes.log of destination compute node that the migration never truly migrates the memory, whenever the reported percentage of memory remaining is close to 0%, it ends up to go back to high percentage again. By looking at the migration UUID, we saw that the memory processed bytes is way higher than the memory total bytes [1]. We played with several `live_migration` options in nova.conf but to no end. Has anyone faced the same issue ? And most importantly, how do you handle the migration of your memory-intensive workload ? Regards, Timothé [1]. $ openstack server migration show 328af6d9-9c9d-4671-a8f9-2c0d3df32b93 e2cda681-e25c-4aca-813c-3641bc6164c9 +------------------------+------------------------------------------------------------------+ | Field | Value | +------------------------+------------------------------------------------------------------+ | ID | 13231 | | Server UUID | 328af6d9-9c9d-4671-a8f9-2c0d3df32b93 | | Status | running | | Source Compute | compute02 | | Source Node | compute02 | | Dest Compute | compute01 | | Dest Host | None | | Dest Node | compute01 | | Memory Total Bytes | 137448202240 | | Memory Processed Bytes | 5300502117730 | | Memory Remaining Bytes | 52182556672 | | Disk Total Bytes | 0 | | Disk Processed Bytes | 0 | | Disk Remaining Bytes | 0 | | Created At | 2026-03-24T10:49:15.000000 | | Updated At | 2026-03-24T13:14:32.000000 | | UUID | e2cda681-e25c-4aca-813c-3641bc6164c9 | | User ID | cc4367e52cce828fa3e378f29ed6df553c2dd99e9a4b33f1835fee719d592c91 | | Project ID | 0382d25c311149fabd7bea0d6fa3ac37 | +------------------------+------------------------------------------------------------------+

2 2

[tc][all][security] Supporting Post-Quantum Cryptography in OpenStack code (all projects)
by Jean-Philippe Jung 25 Mar '26

25 Mar '26

Hi, I am the OpenStack Security Product Manager at Red Hat. I also support Post Quantum Cryptography in OpenStack and k8s (well, OpenShift for us), and I cover some areas of confidential computing. I see one existential risk to OpenStack in the near future: support for post-quantum cryptography (PQC) [0] Based on my latest discussion with industry experts, I expect that around 2029 (likely) or 2030 (at best), there would be powerful enough Q-Computers to break traditional cryptography. Meaning we have to prepare OpenStack to support post-quantum crypto (ML-KEM urgently, ML-DSA as soon as possible) in the upstream code. As we also need to provide time for operators/customers to implement the "fixed" code, we are in early 2028 territory to achieve sufficient PQC coverage in OpenStack upstream. This would give OpenStack users time to implement this code. Time is running out; we’re already almost in 2026! A point to keep in mind is that the initial PQC algorithms might fall short and be replaced in the future. Thus, this PQC support exercise should also be a “cryptographic agility” exercise: we should have a few libraries we know how to call, and if a new crypto algorithm comes out, it should be easy to enable it in the code. I used AI engines to have a look at the OpenStack upstream code (not all projects, but a chunk of the most commonly used), and I came back with 17 different cryptographic modules, 7 of which received no commits in over 2 years. It might be directly in the code or in pulled dependencies. The first step to solving a problem is recognizing we have one. We have a problem. I am seeking help from the TC to raise the urgency of this work across all OpenStack projects and to help me lead an effort to reduce the number of cryptographic modules used in OpenStack (my personal opinion is that there should be no more than five). Doing this may involve work in each OpenStack Project team; and I can help organize this effort. I'm seeking the following from the TC and/or project teams: Portions of this work will be isolated to specific repositories managed by a project team, while others will involve "cross-project" synchronization. What vehicles can we use to have a "call-to-action" for project teams to get someone to look into their specific projects? How can we go about community wide collaboration? I've created a document [1] that I assembled from AI analysis of part of the OpenStack code. It gives an overall view of the problem we face. Looking forward to hearing from you and collaborating upstream to improve OpenStack. Regards, Jean-Philippe (JP) Jung jjung(a)redhat.com irc: jjung [0] Quantum what? Quantum computers will break current encryption algorithms like RSA and elliptic curve cryptography using Shor's algorithm, exposing all data encrypted today. Adversaries are already harvesting encrypted data to decrypt later once quantum computers mature. OpenStack powers critical cloud infrastructure globally. Deploying post-quantum cryptography (PQC) upstream is essential because downstream distributions and deployments inherit these security foundations. Without upstream PQC integration, the entire OpenStack ecosystem remains vulnerable, putting sensitive workloads, government systems, and enterprise data at risk. The migration takes years, so implementing PQC now in the codebase is operationally necessary, not optional. [1] https://wiki.openstack.org/wiki/Post_quantum_openstack

9 18

404 Error while creating event trigger
by mschmitz＠uni-bonn.de 25 Mar '26

25 Mar '26

Hi everyone, I've set up a Kolla-Ansilbe OpenStack 2025.2 test installation with three all-in-one nodes based on Rocky Linux 10. I recently created my first Mistral test workflow. I now wanted to create an event trigger for this workflow. First, I listed the workflow with its ID: [1] Then I tried to create the event trigger, but it failed with the error "Authorization failed: Not Found (HTTP 404)": [2] I'm trying to run the command from an Ansible host. I created the entire deployment from there and can also run all other OpenStack commands via the OpenStack client, so I don't understand how the "Authorization failed" error could occur. The mistral-server.log file for the mistral-api container shows the following when the "openstack event trigger create" is triggered: [3] Does anyone have any idea what exactly I did wrong? Or is there a known bug that causes the error described? Unfortunately, I'm still very new to OpenStack and at this point, I'm really lost on how to proceed. [1] # openstack workflow list +--------------------------------------+------+-----------+----------------------------------+--------+-------+--------+---------------------+---------------------+ | ID | Name | Namespace | Project ID | Tags | Input | Scope | Created at | Updated at | +--------------------------------------+------+-----------+----------------------------------+--------+-------+--------+---------------------+---------------------+ | e2f39063-0160-4629-a266-d3a3eb73ab4c | echo | | b6f8310739a84e54a0ccfd85456a92be | <none> | data | public | 2026-03-24 13:48:14 | 2026-03-25 09:06:34 | +--------------------------------------+------+-----------+----------------------------------+--------+-------+--------+---------------------+---------------------+ [2] # openstack event trigger create first_event_trigger e2f39063-0160-4629-a266-d3a3eb73ab4c cinder notifications.info volume.create.end '{"data":"my first trigger"}' Authorization failed: Not Found (HTTP 404) (Request-ID: req-50e21758-ad86-4420-9b47-f0348d319296) [3] 2026-03-25 11:03:22.311 31 DEBUG keystoneclient.auth.identity.v3.base [None req-f826c10c-8399-4ff3-bfd4-809b36a87c55 e37f0a38743d48c9bd5333b8b66edfa0 b6f8310739a84e54a0ccfd85456a92be - - default default] Making authentication request to http://openstack.mycompany.de:5000/auth/tokens get_auth_ref /var/lib/kolla/venv/lib64/python3.12/site-packages/keystoneclient/auth/identity/v3/base.py:185 2026-03-25 11:03:22.330 31 DEBUG keystoneclient.session [None req-f826c10c-8399-4ff3-bfd4-809b36a87c55 e37f0a38743d48c9bd5333b8b66edfa0 b6f8310739a84e54a0ccfd85456a92be - - default default] Request returned failure status: 404 request /var/lib/kolla/venv/lib64/python3.12/site-packages/keystoneclient/session.py:440 2026-03-25 11:03:22.332 31 ERROR wsme.api [None req-f826c10c-8399-4ff3-bfd4-809b36a87c55 e37f0a38743d48c9bd5333b8b66edfa0 b6f8310739a84e54a0ccfd85456a92be - - default default] Server-side error: "Authorization failed: Not Found (HTTP 404) (Request-ID: req-29671654-e62f-4437-8d51-f13dd95eb4a5)". Detail: Traceback (most recent call last): File "/var/lib/kolla/venv/lib64/python3.12/site-packages/keystoneclient/v3/client.py", line 343, in get_raw_token_from_identity_service return plugin.get_auth_ref(self.session) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/var/lib/kolla/venv/lib64/python3.12/site-packages/keystoneclient/auth/identity/v3/base.py", line 186, in get_auth_ref resp = session.post(token_url, json=body, headers=headers, ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/var/lib/kolla/venv/lib64/python3.12/site-packages/keystoneclient/session.py", line 542, in post return self.request(url, 'POST', **kwargs) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/var/lib/kolla/venv/lib64/python3.12/site-packages/keystoneclient/session.py", line 442, in request raise exceptions.from_response(resp, method, url) keystoneauth1.exceptions.http.NotFound: Not Found (HTTP 404) (Request-ID: req-29671654-e62f-4437-8d51-f13dd95eb4a5) During handling of the above exception, another exception occurred: Traceback (most recent call last): File "/var/lib/kolla/venv/lib64/python3.12/site-packages/wsmeext/pecan.py", line 82, in callfunction result = f(self, *args, **kwargs) ^^^^^^^^^^^^^^^^^^^^^^^^ File "/var/lib/kolla/venv/lib64/python3.12/site-packages/mistral/api/controllers/v2/event_trigger.py", line 75, in post db_model = rest_utils.rest_retry_on_db_error( ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/var/lib/kolla/venv/lib64/python3.12/site-packages/mistral/db/utils.py", line 111, in decorate return retry(_with_auth_context, auth_ctx, func, *args, **kw) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/var/lib/kolla/venv/lib64/python3.12/site-packages/mistral/utils/rest_utils.py", line 271, in __call__ return super(MistralRetrying, self).__call__(fn, *args, **kwargs) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/var/lib/kolla/venv/lib64/python3.12/site-packages/tenacity/__init__.py", line 477, in __call__ do = self.iter(retry_state=retry_state) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/var/lib/kolla/venv/lib64/python3.12/site-packages/tenacity/__init__.py", line 378, in iter result = action(retry_state) ^^^^^^^^^^^^^^^^^^^ File "/var/lib/kolla/venv/lib64/python3.12/site-packages/tenacity/__init__.py", line 400, in <lambda> self._add_action_func(lambda rs: rs.outcome.result()) ^^^^^^^^^^^^^^^^^^^ File "/usr/lib64/python3.12/concurrent/futures/_base.py", line 449, in result return self.__get_result() ^^^^^^^^^^^^^^^^^^^ File "/usr/lib64/python3.12/concurrent/futures/_base.py", line 401, in __get_result raise self._exception File "/var/lib/kolla/venv/lib64/python3.12/site-packages/tenacity/__init__.py", line 480, in __call__ result = fn(*args, **kwargs) ^^^^^^^^^^^^^^^^^^^ File "/var/lib/kolla/venv/lib64/python3.12/site-packages/mistral/db/utils.py", line 59, in _with_auth_context return func(*args, **kw) ^^^^^^^^^^^^^^^^^ File "/var/lib/kolla/venv/lib64/python3.12/site-packages/mistral/services/triggers.py", line 185, in create_event_trigger security.add_trust_id(values) File "/var/lib/kolla/venv/lib64/python3.12/site-packages/mistral/services/security.py", line 110, in add_trust_id trust = create_trust() ^^^^^^^^^^^^^^ File "/var/lib/kolla/venv/lib64/python3.12/site-packages/mistral/services/security.py", line 41, in create_trust client = keystone.client() ^^^^^^^^^^^^^^^^^ File "/var/lib/kolla/venv/lib64/python3.12/site-packages/mistral/utils/openstack/keystone.py", line 29, in client cl = ks_client.Client( ^^^^^^^^^^^^^^^^^ File "/var/lib/kolla/venv/lib64/python3.12/site-packages/keystoneclient/v3/client.py", line 267, in __init__ self.authenticate() File "/var/lib/kolla/venv/lib64/python3.12/site-packages/keystoneclient/httpclient.py", line 594, in authenticate resp = self.get_raw_token_from_identity_service(**kwargs) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/var/lib/kolla/venv/lib64/python3.12/site-packages/keystoneclient/v3/client.py", line 352, in get_raw_token_from_identity_service raise exceptions.AuthorizationFailure( keystoneauth1.exceptions.auth.AuthorizationFailure: Authorization failed: Not Found (HTTP 404) (Request-ID: req-29671654-e62f-4437-8d51-f13dd95eb4a5) : keystoneauth1.exceptions.auth.AuthorizationFailure: Authorization failed: Not Found (HTTP 404) (Request-ID: req-29671654-e62f-4437-8d51-f13dd95eb4a5)

1 0

[qa] Fixing the nodeset for grenade jobs on stable/2025.2 & stable/2026.1
by Ghanshyam Maan 25 Mar '26

25 Mar '26

Hello Everyone, Since 2025.1 testing runtime[1], Ubuntu Noble has been the default distro in testing, but I missed moving the stable/2025.2 and stable/2026.1 grenade jobs to run on Noble; they were still running on Jammy. I am fixing the nodeset now, which will move grenade jobs on those stable branches on Ubuntu Noble. I am testing those in some of the repos[2], and it seems to be working. I would appreciate if you can test it in your projects and report the issues if any. I will keep the changes open till Friday (March 27th) https://review.opendev.org/q/I5cff5bce25aecc6e5058f7fe2fdd02adcb95de4b [1] https://governance.openstack.org/tc/reference/runtimes/2025.1.html#linux-di… [2] https://review.opendev.org/q/topic:%22testing-grenade%22 -gmaan

1 0

April 2026 PTG Team List Announcement
by Kendall Nelson 24 Mar '26

24 Mar '26

Hello Everyone! The April 2026 Project Teams List is official! If your team was planning to meet and isn’t in the list below, please contact ptg(a)openinfra.org IMMEDIATELY. Projects + Teams - OpenInfra Project Teams - Inclusivity WG - Kata Containers - StarlingX - - OpenStack - Services - Blazar - Cinder - Cloudkitty - Cyborg - Designate - Glance - Horizon - Ironic - Keystone - Kolla - Manila - Masakari - Neutron - Nova - Octavia - OpenStack-Ansible - OpenStack-Helm - Tacker - Telemetry - Watcher - Other OpenStack Teams - openstack-i18n - Technical Committee - Adjacent Communities - Yaook <- First time attending a PTG! Welcome! Soon I will be contacting moderators to sign up for time via the PTGBot[1] once it is configured to begin scheduling meeting times. In the meantime, please register if you haven't done so already and encourage your teams to do so as well[2]. As usual, feel free to let us 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: https://ptg.openinfra.org/

2 1

[ops][publiccloud-sig] Public Cloud SIG meeting d.d. 25 March
by Kees Meijs | Nefos 24 Mar '26

24 Mar '26

Hello Stackers, Tomorrow (that's 25 March) the bi-weekly Public Cloud SIG meeting will be held again. The publicly available video meeting will be conducted from 08:05 hrs UTC (09:05 hrs CET) until 08:55 hrs UTC (09:55 hrs CET) here: https://meetpad.opendev.org/publiccloud-sig Additional information to be found on https://wiki.openstack.org/wiki/PublicCloudSIG See you tomorrow! Cheers, Kees __ Kees Meijs BICT Nefos Cloud & IT <https://nefos.com/contact> Nefos IT bv Burgemeester Mollaan 34a 5582 CK Waalre - NL kvk 66494931 +31 (0)88 2088 188 <tel:+31882088188> nefos.com <https://nefos.com/contact> The information contained in this message is intended for the addressee only and may contain classified information. If you are not the addressee, please delete this message and notify the sender; you should not copy or distribute this message or disclose its contents to anyone. Any views or opinions expressed in this message are those of the individual(s) and not necessarily of the organization. No reliance may be placed on this message without written confirmation from an authorised representative of its contents. No guarantee is implied that this message or any attachment is virus free or has not been intercepted and amended. General terms and conditions ("The NLdigital Terms") apply to all our products and services.

1 0

[neutron] Bug deputy report for week of March 16th
by Brian Haley 23 Mar '26

23 Mar '26

Hi, I was the Neutron bug deputy last week. Below is a short summary about the reported bugs. -Brian Critical bugs ------------- * None High bugs --------- * https://bugs.launchpad.net/neutron/+bug/2144529 - Bridge mappings not honored for the external ports while selecting ha_chassis - https://review.opendev.org/c/openstack/neutron/+/980852 Medium ------ * None Low --- * None Invalid ------- * https://bugs.launchpad.net/neutron/+bug/2144979 - [OVN] Add MAC address format validation - Asked for more info Wishlist -------- * https://bugs.launchpad.net/neutron/+bug/2144617 - [RFE] BGP EVPN support for Neutron ML2/OVN backend - Asked Helen to add to future Driver's agenda - Discussed March 20th * https://bugs.launchpad.net/neutron/+bug/2144977 - [RFE] Add --port option to remove-duplicated-port-bindings script - Asked Kyuyeong to add to future Driver's agenda - On agenda for March 27th

1 0

March 17 Digital Sovereignty Meeting Recording & Plan Going Forward
by Kendall Nelson 23 Mar '26

23 Mar '26

Hello Everyone! Thank you to those who were able to attend yesterday's meeting. We really appreciate you taking time out of our day to support collaboration around OpenInfra and Digital Sovereignty. For those that were unable to attend, here is the recording! https://zoom.us/rec/share/5C87PC0AwqXFVCeW-f0ydLppVrEsUSuvRyV_M9xSgvPcVq7ZF… As always, please note in our etherpad <https://etherpad.opendev.org/p/Digital-Sovereignty-WG> that you have watched the recording and feel free to add your own notes as well. Just because you are not able to make it to all the meetings, doesn't mean you don't have valuable insight - we want to hear from you. Now, as to how our efforts are going - since we are in a good place with the landing page, link coming soon - we are going to take a few weeks to break into smaller groups to work on some of the deliverables and make our next big meeting during the PTG (April 20-24) with that exact timing TBD via a poll in a couple weeks. *If there is a particular deliverable (case studies, best practices, proprietary v openstack, and thought leadership blogs) please make sure to add your name to those sections (and email address to the attendees section) of the etherpad <https://etherpad.opendev.org/p/Digital-Sovereignty-WG> by the end of the week so I can set up individual threads for those subgroups. * Any questions? Please feel free to ask! -Kendall

1 1

[tc][all] OpenStack Technical Committee Weekly Summary and Meeting Agenda (2026.1/R-1)
by gouthampravi＠gmail.com 23 Mar '26

23 Mar '26

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hello Stackers, We're a week away from the coordinated release of OpenStack 2026.1 "Gazpacho" [1]. Project teams continue to test for release-critical bugs and will publish additional RCs if necessary. All "cycle-with-rc" deliverables have now switched over to the 2026.2 "Hibiscus" release cycle [2]. The Project Team Lead election results were announced [3] last week and the governance changes for nearly 40 project teams were merged. For the handful of leaderless projects we discussed last week, the OpenStack Technical Committee fast-tracked the appointment changes that had been soaking without objection. Please join me in congratulating all the new and returning PTLs and project liaisons. Callum Dickinson (Callum027), Douglas Viroel (dviroel), Erkin Mussurmankulov (Riki_tiki_tavi) and Sean Mooney (sean-k-mooney) are first-time PTLs for the OpenStack Adjutant, Watcher, Trove and Cyborg project teams. Thank you all for stepping up to perform this critical duty. The TC appointed Arnaud Morin (amorin) as PTL for Mistral and Wenxiang Wu (wenxiang_wu) as PTL for Skyline. The DPL model was restored for Requirements and Oslo with a refreshed list of liaisons. Amy Marrich (spotz) is at KubeCon EU in Amsterdam this week. Do say hello if you run into her. On the CI front, it's been a rough couple of weeks. Opendev websites have been going down repeatedly, and that's been hitting CI, developers, users and operators. If you're plugged into IRC, you know the kind of fire fighting the opendev team has been handling. Thank you to everyone who's been keeping the lights on through all of this. === Weekly Meeting === The last weekly meeting of the OpenStack Technical Committee was held on March 17, 2026 [4]. The bulk of the meeting centered around leaderless teams. A past PTL of the Blazar project offered to step in as PTL of the Masakari project team and mentor other project contributors towards governance roles. The TC was supportive of this: Dan Smith (dansmith) put it well that mentoring a new PTL is an opportunity we shouldn't pass up. The discussion then shifted to Venus and Vitrage. Both these project teams were marked "inactive" [5] with no PTL candidates in the 2026.1 release cycle. Dmitriy Rabotyagov (noonedeadpunk) wondered whether we should deprecate rather than retire them, since retirement deletes stable branches while deprecation keeps them around for security patches. Jeremy Stanley (fungi) reminded us that deprecation doesn't prevent stable point releases, and Ghanshyam Maan (gmaan) noted that retirement at least gives operators honest visibility. At the moment, the TC favors deprecating Vitrage (noonedeadpunk offered to help maintain the stable branches) and retiring Venus (we have identified no maintainers). The release team's proposal to remove both from the Gazpacho coordinated release [6] got TC support. I also shared the TC's PTG etherpad [7]. We've reserved time and I'm hoping we will discuss existing and new community goals, alongside other governance and cross project topics. The next meeting of the OpenStack TC is Tuesday March 24, 2026, at 1700 UTC. This meeting will be hosted on the #openstack-tc channel on OFTC. Please see the agenda on the meeting's wiki page [8]. I hope to see you there. === Governance Proposals === ==== Merged ==== - - Appoint Arnaud Morin as PTL for mistral | https://review.opendev.org/c/openstack/governance/+/977344 - - Restore DPL model for requirements project | https://review.opendev.org/c/openstack/governance/+/977547 - - Revert "Reset the DPL model for Oslo project" | https://review.opendev.org/c/openstack/governance/+/977707 - - Add PTL results from the 2026.2 election | https://review.opendev.org/c/openstack/governance/+/981311 - - Appoint Wenxiang Wu as PTL of Skyline | https://review.opendev.org/c/openstack/governance/+/978067 - - Appoint Callum Dickinson as PTL for Adjutant | https://review.opendev.org/c/openstack/governance/+/978842 ==== Open for Review ==== - - Appoint Masahito Muroi as PTL of Masakari | https://review.opendev.org/c/openstack/governance/+/981213 - - Retire requestsexceptions | https://review.opendev.org/c/openstack/governance/+/979815 - - Revert "Revive os_monasca" | https://review.opendev.org/c/openstack/governance/+/974775 === Upcoming Events === - - 2026-03-23: KubeCon/CloudNativeCon EU (Amsterdam): https://events.linuxfoundation.org/kubecon-cloudnativecon-europe/ - - 2026-03-23: Open Source SecurityCon Europe (Amsterdam): https://openssf.org/event/open-source-securitycon-2026/ - - 2026-04-02: OpenInfra Live: https://openinfra.org/live/ - - 2026-04-14: OpenInfra Board Meeting: https://board.openinfra.org/ - - 2026-04-20: OpenInfra PTG begins: https://openinfra.org/ptg/ - - 2026-04-25: OpenInfra Days, Nigeria: https://www.meetup.com/openstack-nigeria-user-group/events/313525373/ === 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 on OFTC. 3. Join us at our weekly meeting: The Technical Committee meets every Tuesday at 1700 UTC, except the third Tuesday of the month, when we meet at 0800 UTC [8]. Thank you very much for reading! On behalf of the OpenStack TC, Goutham Pacha Ravi (gouthamr) OpenStack TC Chair [1] 2026.1 "Gazpacho" Release Schedule: https://releases.openstack.org/gazpacho/schedule.html [2] 2026.2 "Hibiscus" Release Schedule: https://releases.openstack.org/hibiscus/schedule.html [3] PTL Election Results for 2026.2: https://governance.openstack.org/election/results/2026.2/ptl.html [4] TC Meeting IRC Log, March 17 2026: https://meetings.opendev.org/meetings/tc/2026/tc.2026-03-17-17.00.html [5] Venus and Vitrage marked inactive: https://review.opendev.org/q/project:openstack/governance+(inactive+vitrage… [6] Remove vitrage and venus from 2026.1 Gazpacho: https://review.opendev.org/c/openstack/releases/+/980900 [7] TC PTG Etherpad: https://etherpad.opendev.org/p/apr2026-ptg-os-tc [8] TC Meeting Agenda, March 24 2026: https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Next_Meeting -----BEGIN PGP SIGNATURE----- iQJPBAEBCAA5FiEEwo5Vl+U+phfaPpN5Bjja07gsOYgFAmnBiC0bFIAAAAAABAAO bWFudTIsMi41KzEuMTIsMCwzAAoJEAY42tO4LDmIMpgQAI5o/GrdkeLCpuBkJXJJ 6mhWq3ZBxcbeuzk+GvqB4d4FNJL16H44Exf9e/OV2ZGFUchp8K8lm8x9BLmVydyl 0cvoIng7CnzjUGd6DCeubQrMQqb/zL65HUwnICAQpcproXXfWWt5i+V70IRU9cjA i2ZJng9dEbdlvlZ6i40OiCC7Dj8xh06OUXJqvOFKLUfVfiLlXMR9D2MYW3kBQQUf insxDn8BYXhK9MmDp0yvKjesQG91uaE7aqdLYroTHm+tIEk7qn1ikpZ41VFRotUq CTYpq6uTJQ7T6vpTX+6zEQqAhAjAyOQzKlsKLWIJvncE5zX7EDMANGw3jAo8WVmA 2ek2Z4+ME37/7rQVAmM2QicaA0spHJZsK36o5lYy+iCKwYorrcKchet3A7DfyZZ0 z7W0lRNEuiGQ/5IreM9tz+6VeuujkoCg2z7uU1pY+Db+DGP5OwOrnYb0SLuXbnYU Kz2h697Khwp2UEd8A9uhdJYEeJwL2mjQ2InababBsxd0pG14QjH53gd78+QAUlFF l185/6wICfQYKd3D1VryJPAe+C6UexDqW/1XQ6jou1jX9+7MCKXmHw4AT0NSJ22O gqFjGRmBUSstpgbN9iYRWQWfDtXmH0p9yV5bYWymPZAvtzFQ87bj3qyaWF10IwEU KPw7qdqb+FxznOFYp7c1B4hx =yOr/ -----END PGP SIGNATURE-----

1 0

[swift] eventlet removal status
by Christian Schwede 23 Mar '26

23 Mar '26

Hi, There is a series of patches to remove eventlet from Swift proposed: https://review.opendev.org/q/project:openstack/swift+topic:eventlet-removal… With these patches applied, Swift runs using Gunicorn as the WSGI server and uses threading (if eventlet is not installed or is disabled using the environment variable USE_EVENTLET=0). Eventlet modules have been mostly replaced by modules from Python's standard library. The current testing status is as follows: Functional: 100% passing Unit: 99% passing Probe: ~97% passing (some tests are flaky, which might be unrelated; 3% are logline mismatches in test/probe/test_signals.py) If you want to start testing without deploying a Swift cluster, the simplest way is to check out the feature/threaded branch, create a virtualenv and run unittests and/or in-process functional tests. For example: git clone -b feature/threaded https://github.com/cschwede/swift.git # Copy of the proposed patches cd swift virtualenv .venv312 -p python3.12 source .venv312/bin/activate pip install -r requirements.txt pip install -r test-requirements.txt pip uninstall -y eventlet To run in-process functional tests: SWIFT_TEST_IN_PROCESS=1 ./.functests Unit tests can be run with ./.unittests; however, due to the still large amount of failures (~95 out of 10.000+ tests still failing) pytest might crash with a MemoryError. I do run these tests per directory for the moment, eg: ./.unittests obj ./.unittests proxy If you want to test an actual Swift deployment without eventlet (and run probetests), I recommend using a Swift-All-In-One (SAIO) deployment, as documented in [1]. If using [2] you can simply point it to the feature/threaded branch on my Github account, eg: export SWIFT_REPO=https://github.com/cschwede/swift export SWIFT_REPO_BRANCH=feature/threaded I recommend uninstalling eventlet within the SAIO VM for testing; this ensures Swift truly works without eventlet. Most test failures are related to timeouts and disconnects, especially when using EC. Some of them are related to blocking "queue.put" if the client is already gone and threads wait infinitely (this is also the reason why "pytest" does not exit after running "pytest test/unit/proxy"). Other test failures result from different result ordering (eventlet yields in a deterministic order; threading results are somewhat random, depending on the OS scheduler). I'm looking into possible solutions for this. If you want to benchmark the gunicorn-based deployment, you might want to change the "threads = 4" setting in the *-server.conf files. This (low) number should most likely be increased to achieve better performance. Any help with reviewing, testing, benchmarking and fixing the remaining issues is very welcome! Thanks, Christian [1] https://docs.openstack.org/swift/latest/development_saio.html [2] https://github.com/NVIDIA/vagrant-swift-all-in-one -- Red Hat GmbH <https://www.redhat.com/de/global/dach>, Registered seat: Werner von Siemens Ring 12, D-85630 Grasbrunn, Germany Commercial register: Amtsgericht Muenchen/Munich, HRB 153243, Managing Directors: Ryan Barnhart, Charles Cachera, Avril Crosse O'Flaherty

1 0