- openstack-discuss - lists.openstack.org

[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

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

20 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

8 13

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

20 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 20 Mar '26

20 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 19 Mar '26

19 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

[qa] Canceling today QA office hour
by Ghanshyam Maan 19 Mar '26

19 Mar '26

Due to another conflict, I will cancel today's office hour. The next office hours will be on 1st April. https://wiki.openstack.org/wiki/Meetings/QATeamMeeting#Details -gmaan

1 0

[cinder] festival of reviews friday 2026-03-20
by Brian Rosmaita 18 Mar '26

18 Mar '26

Hello Argonauts, It's already the third week of March, which means that the twice monthly Cinder Festival of Reviews will be held at the end of this week on Friday 20 March. who: Everyone! what: The Cinder Festival of Reviews when: Friday 20 March 2026 from 1400-1600 UTC where: videoconf info on the etherpad etherpad: https://etherpad.opendev.org/p/cinder-festival-of-reviews This recurring meeting, that happens on the first and third Friday of each month, can be placed on your calendar by using this handy ICS file: https://meetings.opendev.org/calendars/cinder-festival-of-reviews.ics See you there!

1 0

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

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

[cinder][ops] Migrate volume backend from decommissioned node
by Isaac Vicente 18 Mar '26

18 Mar '26

Hello all, In the past week I've added a new controller and decommissioned an old one, following the official documentation [1], and I wrote a version of my own [2], specific to my environment. In the section "Removing existing controllers", it's necessary to move agents and remove services of the node that will be decommissioned. So far so good, until I realize that a volume has the following property: os-vol-host-attr:host: <old_node>@rbd-1#rbd-1 It means that this volume is still on the backend of the removed node. So I tried to migrate it to another backend, and the migration status is "starting" for a long time. In the cinder-scheduler logs: WARNING cinder.scheduler.host_manager volume service is down. (host: <old_node>@rbd-1) To me, the migration stays in this status because the proper backend is down. To mention, I'm using Ceph as cinder backend. Also, there's no mention of the volume being migrated on other controller nodes. Is there any method to migrate all volumes of this backend without needing to re-deploy the old controller? Versions: - Openstack: caracal (2024.1) - OS: Ubuntu 22.04 - kolla-ansible: 18.8.1 [1] https://docs.openstack.org/kolla-ansible/latest/user/adding-and-removing-ho… [2] https://isaacvicente.github.io/posts/replacing-control-nodes-with-kolla-ans…

3 4