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

[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

[all][elections][ptl] 2026.2 Hibiscus: PTL Election Conclusion and Results
by Ian Y. Choi 19 Mar '26

19 Mar '26

Thank you to the electorate, to all those who voted and to all candidates who put their name forward for Project Team Lead (PTL) in this election. A healthy, open process breeds trust in our decision making capability thank you to all those who make this process possible. Now for the results of the PTL election process, please join me in extending congratulations to the following PTLs: * Barbican : Mauricio Harley * Blazar : Matt Crees * Cinder : Jon Bernard * Cloudkitty : Rafael Weingartner * Cyborg : Sean Mooney * Designate : Omer Schwartz * Glance : Cyril Roelandt * Heat : Takashi Kajinami * Horizon : Tatiana Ovchinnikova * Keystone : Artem Goncharov * Kolla : Michal Nasiadka * Magnum : Michal Nasiadka * Manila : Carlos Silva * Neutron : Brian Haley * Nova : René Ribaud * Octavia : Gregory Thiemonge * OpenStack Charms : Felipe Reyes * OpenStack Helm : Vladimir Kozhukalov * OpenStackAnsible : Dmitriy Rabotyagov * OpenStackSDK : Artem Goncharov * Puppet OpenStack : Takashi Kajinami * Quality Assurance : Ghanshyam Maan * Rally : Andrey Kurilin * Storlets : Takashi Kajinami * Sunbeam : Guillaume Boutry * Swift : Tim Burke * Tacker : Yasufumi Ogawa * Telemetry : Juan Larriba * Trove : Erkin Mussurmankulov * Watcher : Douglas Viroel * Zaqar : Hao Wang * Zun : Hongbin Lu Elections: * Barbican: https://civs1.civs.us/cgi-bin/results.pl?id=E_1d8fdb64270e5b0d * Horizon: https://civs1.civs.us/cgi-bin/results.pl?id=E_0fff229065ebe3db Election process details and results are also available here: https://governance.openstack.org/election/ Thank you to all involved in the PTL election process,

2 1

[OSSA-2026-004] Glance: Server-Side Request Forgery (SSRF) vulnerabilities in OpenStack Glance image import functionality (CVE-2026-pending)
by Brian Rosmaita 19 Mar '26

19 Mar '26

==================================================================== OSSA-2026-004: Server-Side Request Forgery (SSRF) vulnerabilities in OpenStack Glance image import functionality ==================================================================== :Date: March 19, 2026 :CVE: CVE-2026-pending Affects ~~~~~~~ - Glance: <29.1.1, >=30.0.0 <30.1.1, ==31.0.0 Description ~~~~~~~~~~~ Hyeongeun_Ji of Open the Window and Abhishek Kekane of Red Hat reported multiple Server-Side Request Forgery (SSRF) vulnerabilities in Glance image import. By use of HTTP redirects, an authenticated user can bypass URL validation checks and redirect to internal services. Only glance image import functionality is affected. In particular, the 'web-download' and 'glance-download' import methods are subject to this vulnerability, as is the optional (not enabled by default) 'ovf_process' image import plugin. We discuss each of the vulnerabilities in turn below. web-download Import Method SSRF ------------------------------- The web-download import method has two SSRF vulnerabilities: HTTP Redirect Bypass ++++++++++++++++++++ The web-download import method did not validate redirect destinations when following HTTP redirects. An attacker could provide an initial URL that passed validation but redirected to an internal or disallowed resource; the redirected URL was not subject to security checks. This is fixed by implementing a SafeRedirectHandler that validates redirect destinations before following them, using same validate_import_uri() checks as the initial URL. IP Address Encoding Bypass ++++++++++++++++++++++++++ The web-download import method URL validation could be bypassed by encoding IP addresses in alternative formats (decimal integer, hexadecimal, octal). For example, 127.0.0.1 could be encoded as 2130706433 (decimal) or 0x7f000001 (hexadecimal) to bypass blacklist checks. This is fixed by implementing a normalize_hostname() function that uses the Python standard library ipaddress module to validate IP addresses. The ipaddress module only accepts standard dotted-decimal notation for IPv4 and standard format for IPv6, automatically rejecting all encoded formats (decimal, hexadecimal, octal). Any attempt to use encoded IP formats is rejected, thereby preventing SSRF bypass attacks. glance-download Import Method SSRF ---------------------------------- The glance-download import method had redirect validation bypass vulnerabilities in two steps of the import flow: Image Data Download +++++++++++++++++++ When downloading image data from a remote Glance endpoint, redirects were not validated, allowing attackers to redirect to internal services. Metadata Fetch ++++++++++++++ When fetching image metadata from a remote Glance endpoint, redirects were not validated, allowing attackers to redirect to internal services. Both steps are fixed by using the SafeRedirectHandler described earlier to validate redirect destinations before following them. OVF Processing SSRF ------------------- The OVF processing functionality had critical SSRF vulnerability with zero protection - no URI validation, no redirect validation, and no IP normalization. The code directly called urllib.request.urlopen(uri) without any validation checks. This is fixed by adding URI validation using validate_import_uri() and redirect validation using SafeRedirectHandler. Patches ~~~~~~~ - https://review.opendev.org/981300 (2023.1/antelope) - https://review.opendev.org/981299 (2024.2/dalmatian) - https://review.opendev.org/981298 (2025.1/epoxy) - https://review.opendev.org/981297 (2025.2/flamingo) - https://review.opendev.org/981296 (2026.1/gazpacho) - https://review.opendev.org/981295 (2026.2/hibiscus) Credits ~~~~~~~ - Hyeongeun_Ji from Open the Window (CVE-2026-pending) - Abhishek Kekane from Red Hat (CVE-2026-pending) References ~~~~~~~~~~ - https://launchpad.net/bugs/2138602 - https://launchpad.net/bugs/2138672 - https://launchpad.net/bugs/2138675 - http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2026-pending Notes ~~~~~ - A CVE request was filed with MITRE on 2026-02-16. - Prereleases of OpenStack software are not official production releases and so not covered by the affected versions list. The first Glance release candidate for gazpacho (32.0.0.0rc1) is vulnerable; 32.0.0.0rc2 will contain the fix. - The unmaintained/2023.1 branch, being unmaintained, will receive no new point releases, but a patch for it is provided as a courtesy.

1 0

[Masakari] team meeting today at 07:00-08:00 UTC
by Sei Sano 19 Mar '26

19 Mar '26

Hi team Apologies for the short notice ― just a reminder that we have our regular team meeting today. When: 07:00 UTC, <day>, <date> Where: #openstack-masakari (OFTC) Agenda: https://etherpad.opendev.org/p/masakari-meeting-2026.1 If you have any topics to discuss, please add them to the agenda. Thanks, Sei Sano

6 9

[all][elections][ptl][barbican][horizon] PTL 2026.2 cycle Election Voting Last Days
by Ian Y. Choi 18 Mar '26

18 Mar '26

We are coming down to the last hours for voting in the Barbican, Horizon elections. Voting ends Mar 18, 2026 23:45 UTC. Search your Gerrit preferred email address[0] for the messages with subjects like... OpenStack 2026.2 Cycle - Barbican PTL Election Poll OpenStack 2026.2 Cycle - Horizon PTL Election Poll That is your ballot and links you to the voting application. Please vote. If you have voted, please encourage your colleagues to vote. Candidate statements are linked to the names of all confirmed candidates: https://governance.openstack.org/election/ What to do if you don't see the email and have a commit in at least one of the official project teams' deliverable repositories[1]: * check the trash of your gerrit Preferred Email address[0], in case it went into trash or spam * find the ID of at least one commit merged to an official deliverable repo[1] over the current and previous cycles, confirm you are an Open Infrastructure Foundation Individual Member[2], and then email the election officials[3] or get in touch in the #openstack-election channel on the Freenode IRC network. If we can confirm that you are entitled to vote, we will add you to the voters list and you will be emailed a ballot. Please vote! Thank you, [0] Sign into review.openstack.org and go to Settings > Contact Information. Look at the email listed as your Preferred Email. That is where the ballot has been sent. [1] https://opendev.org/openstack/governance/src/tag/to-be-released/reference/p… [2] https://www.openstack.org/profile/ [3] https://governance.openstack.org/election/#election-officials

1 0