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

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

24 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

[oslo] Proposal to add Ghanshyam Maan as core team
by Daniel Mats Niklas Bengtsson 23 Mar '26

23 Mar '26

Hi everyone, I hope you are all doing well. I would like to propose adding Ghanshyam Maan to the oslo core team. Ghanshyam has been actively contributing to the Oslo libraries for some time. He regularly participates in technical discussions, including work around multiprocessing, provides thoughtful and constructive code reviews, and has contributed several solid patches. He is also currently serving as the TACT-SIG liaison and has offered to take on the role of release liaison as well. His consistent involvement in reviews and project discussions demonstrates a strong commitment to the Oslo projects and to the OpenStack community. I believe he would be a great addition to the oslo core team. Please reply with your votes (+1 / 0 / -1). The vote will remain open for one week.

4 3

[ansible-collections-openstack] two patches ready for review
by Taavi Ansper 23 Mar '26

23 Mar '26

Hi Who should I assign for review from cores? Two simple fixes ready. One has been tested by other +1 https://review.opendev.org/c/openstack/ansible-collections-openstack/+/9775… https://review.opendev.org/c/openstack/ansible-collections-openstack/+/9815… Best regards taavi ansper

1 0

[dev][nova] Intel TDX support
by Anton Iacobaeus 23 Mar '26

23 Mar '26

Hi, I work with confidential computing and has previously contributed to Proxmox [1] to enable support for Intel TDX. I am looking to do the same for Openstack Nova. I have proposed a blueprint [2] and am drafting a spec with target for 2026.2 release. From what I gather, support for AMD SEV and SEV-ES is already implemented in Nova, while SEV-SNP support is ongoing. TDX shares some commonalities with SEV-SNP, and I believe that the work on both can be conducted in tandem. I also have experience with SEV-SNP and am happy to contribute if needed. Early feedback or any concerns and guidance are very welcome! [1] https://pve.proxmox.com/wiki/Roadmap#Proxmox_VE_9.1 [2] https://blueprints.launchpad.net/nova/+spec/intel-tdx-libvirt-support Best Regards, Anton

4 5

[ops][largescale-sig][scientific-sig][publiccloud-sig] Ops Radio Hour on March 27, 2026
by Ildiko Vancsa 23 Mar '26

23 Mar '26

Hi OpenStack community, I'm reaching out to you with a friendly reminder that the next OpenStack Ops Radio Hour[1] is scheduled to happen on __March 27th, 2026 at 1300UTC,__ which is this Friday! The call series is a casual setting for operators, engineers, and contributors to come together, share knowledge, and collaborate on the complexities of managing and deploying OpenStack environments. The main topic the group identified for the upcoming call is OVN: - Migrating to OVN - OVN experiences and practices If you have any experience with OVN, or thinking about migrating to it, please make sure to join the call! If you have further topics you would like to dive into during the call, please add them to this etherpad: https://etherpad.opendev.org/p/openstack_ops_radiohour A few reminders: - The group on the call agreed to try out Matrix as a chat platform for more synchronous communication outside calls + You can access the Matrix room here: https://matrix.to/#/#openstack-ops:opendev.org<https://matrix.to/#/%23openstack-ops:opendev.org> <https://matrix.to/#/%23openstack-ops:opendev.org%3Chttps://matrix.to/%23/%2…> + Further details are here: https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack… - If you would like to read and catch up on notes from previous calls, you can find them in this etherpad: https://etherpad.opendev.org/p/openstack_ops_radiohour See you on the call on March 27th! Bets Regards, Ildikó [1] https://wiki.openstack.org/wiki/Operations/Meetups

1 0

Introduction - Outreachy Applicant Interested in Ironic
by Aman 23 Mar '26

23 Mar '26

Hello everyone, My name is Aman, and I am a software engineer and an Outreachy applicant interested in contributing to OpenStack, particularly the Ironic project. I have a background in Computer Science. My technical skills include: Languages: Python, JavaScript, SQL, NoSQL (MongoDB) Frontend: HTML5, CSS3, ReactJS Backend: Node.js, Express.js, REST APIs Databases: MySQL, MongoDB Cloud & DevOps: Docker, Git, Linux, basic AWS (EC2, S3), CI/CD (GitHub Actions) Machine Learning: Currently learning Machine Learning, Deep Learning, and Reinforcement Learning Currently, I am exploring the Ironic codebase and working on tasks related to node deployment history APIs. I am looking forward to learning from the community and contributing meaningfully. I would appreciate any guidance or pointers on how I can get more involved. Thank you. Best regards, Aman

1 0

[neutron] Weekly Meetings new timing effective from today
by Yatin Karel 23 Mar '26

23 Mar '26

Hi Neutrinos, As discussed in last week's meeting, starting from today, the Neutron and Neutron CI meetings will occur an hour earlier. More context is in [1]. Neutron CI Meeting: Every Monday at 1400 UTC Neutron Meeting: Every Tuesday at 1300 UTC [1] https://review.opendev.org/c/opendev/irc-meetings/+/980731 -- Thanks and Regards Yatin Karel

1 0

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

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

[ironic] Outreachy Applicant Introduction – OpenStack Ironic
by Kelvin Asante 21 Mar '26

21 Mar '26

Hello, My name is Kelvin Asante, and I’m an Outreachy applicant interested in contributing to the OpenStack Ironic project. I have experience with Python, Git, and Linux. I’m currently improving my understanding of open source contribution workflows and the OpenStack ecosystem. I’ve joined the IRC channel and started going through the contributor documentation. I’m excited to begin contributing and learning from the community. Thank you for your time, and I look forward to working with you and the community. Best regards, Kelvin Asante

1 0

[release] Release countdown for week R-1
by Thierry Carrez 20 Mar '26

20 Mar '26

Development Focus ----------------- We are on the final mile of the 2026.1 "Gazpacho" development cycle! Remember that the 2026.1 "Gazpacho" final release will include the latest release candidate (for cycle-with-rc deliverables) or the latest intermediary release (for cycle-with-intermediary deliverables) available. March 26 is the deadline for final 2026.1 "Gazpacho" release candidates as well as any last cycle-with-intermediary deliverables. We will then enter a quiet period until we tag the final release on April 1st, 2026. Teams should be prioritizing fixing release-critical bugs, before that deadline. Otherwise it's time to start planning the 2026.2 "Hibiscus" development cycle, including discussing upcoming PTG sessions content. Actions ------- Watch for any translation patches coming through on the stable/2026.1 branch and merge them quickly. If you discover a release-critical issue, please make sure to fix it on the master branch first, then backport the bugfix to the stable/2026.1 branch before triggering a new release. Please drop by #openstack-release with any questions or concerns about the upcoming release ! Upcoming Deadlines & Dates -------------------------- Final RC deadline: March 26th, 2026 (R-1 week) Final 2026.1 "Gazpacho" release: April 1st, 2026 2026.2 "Hibiscus" (virtual) PTG: April 20-24, 2026 -- Thierry Carrez (ttx)

1 0