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

[release] Release countdown for week R+0, Mar 30 - Apr 03
by Elõd Illés 27 Mar '26

27 Mar '26

Development Focus ----------------- We will be releasing the coordinated OpenStack 2026.1 Gazpacho release next week, on April 1st, 2026. Thanks to everyone involved in the 2026.1 Gazpacho cycle! We are now in pre-release freeze, so no new deliverable will be created until final release, unless a release-critical regression is spotted. Otherwise, teams attending the virtual PTG should start to plan what they will be discussing there, by creating and filling team etherpads. You can access the list of PTG etherpads at: https://ptg.opendev.org/etherpads.html General Information ------------------- On release day, the release team will produce final versions of deliverables following the cycle-with-rc release model, by re-tagging the commit used for the last RC. A patch doing just that will be proposed. PTLs and release liaisons should watch for that final release patch from the release team. While not required, we would appreciate having an ack from each team before we approve it on the 1st, so that their approval is included in the metadata that goes onto the signed tag. Upcoming Deadlines & Dates -------------------------- Final 2026.1 "Gazpacho" release: April 1st, 2026 2026.2 "Hibiscus" (virtual) PTG: April 20-24, 2026 Előd Illés irc: elodilles @ #openstack-release

1 0

Upcoming metrics dashboard changes
by Ildiko Vancsa 27 Mar '26

27 Mar '26

Hi OpenStack community, Since the OpenInfra Foundation joined the Linux Foundation, we have been looking into opportunities to take advantage of the frameworks and tool sets that the Linux Foundation has, and some of you and your organizations are already familiar with. While the dashboards are still being built I would like to let you know that, as part of that effort, we will switch to LFX Insights[1] as the metrics dashboard for OpenInfra projects, including OpenStack, starting on __January 15, 2026.__ A couple things to note: - The new OpenStack metrics dashboard[2] is already available, but it is __still under active construction.__ - The set of metrics that is displayed on the new dashboard will not be identical with the metrics on the dashboard provided by Bitergia. - LFX Insights does not display affiliation information for individuals who are listed on the dashboard as contributors, for privacy reasons. However, if you already have an LF account[3], you will be able to check and update your affiliation information. Or, you can create a new LF account[4]. - You can learn more about the dashboard in the LFX Insights documentation[5]. - If your organization is an OpenInfra Foundation / Linux Foundation member already, the LF Organization Dashboard[6] is also available for a more company-centric view. The OpenStack Bitergia metrics dashboard[7] remains available __until January 14, 2026.__ Please let me know if you have any questions. Best Regards, Ildikö [1] https://insights.linuxfoundation.org/ [2] https://insights.linuxfoundation.org/project/OpenStack/ [3] https://openprofile.dev/ [4] https://docs.linuxfoundation.org/lfx/sso/create-an-account [5] https://insights.linuxfoundation.org/docs/introduction/what-is-insights/ [6] https://lfx.linuxfoundation.org/tools/organization-dashboard/ [7] https://openstack.biterg.io/ ——— Ildikó Váncsa Director of Community OpenInfra Foundation

4 9

Status of Debian packages for Gazpacho
by Thomas Goirand 27 Mar '26

27 Mar '26

tl;dr: Gazpacho Debian packages are ready and tempest validated! Hi, Just wanted to write a quick message to tell the community that I have been able to mostly validate all of the Gazpacho release, a few days before the final release. The last issues in glance-store and os-ken (upstream bugs in these components) have been addressed quickly, thanks to the reactivity of both Abhishek Kekane and lajoskatona respectively, which is very much appreciated! As the issue with os-ken prevented my CI to properly test Octavia and other stuff, I'll restart the tests, however, results are showing that everything else seems working. As always, the packages are available through the unofficial osbpo.debian.net repositories if you wish to use the backports to Debian Stable (Trixie), which can be managed with extrepo: apt-get install extrepo extrepo enable openstack_gazpacho apt-get update I'm at the moment uploading everything to Debian Unstable as well, even if this currently means that I'm uploading the RC releases. Thanks to everyone involved in this release. OpenStack continues to be an awesome community to work with! I sincerely hope my constant efforts to have always up-to-date Debian package as soon as possible, with enough unit and functional tests to guarantee a quality standard will continue to help Debian users, Cheers, Thomas Goirand (zigo) P.S: The real-time status of OpenStack Debian packaging continues to be available at https://osbpo.debian.net/deb-status/

1 0

Status of Debian package for Gazpacho
by Thomas Goirand 27 Mar '26

27 Mar '26

tl;dr: Gazpacho Debian packages are ready and tempest validated! Hi, Just wanted to write a quick message to tell the community that I have been able to mostly validate all of the Gazpacho release, a few days before the final release. The last issues in glance-store and os-ken (upstream bugs in these components) have been addressed quickly, thanks to the reactivity of both Abhishek Kekane and lajoskatona respectively, which is very much appreciated! As the issue with os-ken prevented my CI to properly test Octavia and other stuff, I'll restart the tests, however, results are showing that everything else seems working. As always, the packages are available through the unofficial osbpo.debian.net repositories if you wish to use the backports to Debian Stable (Trixie), which can be managed with extrepo: apt-get install extrepo extrepo enable openstack_gazpacho apt-get update I'm at the moment uploading everything to Debian Unstable as well, even if this currently means that I'm uploading the RC releases. Thanks to everyone involved in this release. OpenStack continues to be an awesome community to work with! I sincerely hope my constant efforts to have always up-to-date Debian package as soon as possible, with enough unit and functional tests to guarantee a quality standard will continue to help Debian users, Cheers, Thomas Goirand (zigo) P.S: The real-time status of OpenStack Debian packaging continues to be available at https://osbpo.debian.net/deb-status/

1 0

Windows Instance Performance - Possible issues with VirtIO Drivers
by Joel McLean 27 Mar '26

27 Mar '26

G'day Openstackers. I've found myself down a rabbit hole that I think will get me nowhere; but I wanted to query the list to see whether people are seeing the same, or whether what I'm experiencing can be mitigated, if someone here has seen this behaviour. We are running an Openstack (caracal 2024.1) with Libvirt/qemu as the guest agent. Storage is all cinder volumes on a stand-alone storage platform - an NVMe Ceph (reef) Cluster provided to Openstack via Cinder. For Windows virtual machines, we are installing VirtIO drivers ( https://docs.openstack.org/image-guide/create-images-manually-example-windo… ) and have tried a variety of driver versions (0.1.285-1, 0.1.271-1, 0.1.262-2, 0.1.248-1) and while they all work, we have noticed significant different in performance between throughput and IO operations compared to virtual machines running on Ubuntu. The performance differences are most notable in a real-world workload test using - a MySQL 8 database - same CPU and Memory Configuration Flavor, same volume_type - same MySQL configuration - we run a query that checks for missing indexes, then creates ~500K missing indexes. On the Ubuntu 24 instance the task completes in ~17 minutes, On the Windows 2025 instance, the task completes in ~29 minutes. Testing to compare against a Hyper-V compute host, with the same performance drives, except as locally attached NVMe drives, performance for the same task in Windows 2025 is ~17 minutes. Testing the windows instance with different VirtIO (vioscsi, or viostor) didn't significantly impact the task completion time; it averaged between 29 and 35 minutes depending on which driver was in use. In Ceph, there's no errors to speak of, all logs are nominal in Ceph when comparing RBD claims (i.e. Linux vs Windows) So, we're pretty sure the issue is how Windows Instances consume storage. This behaviour is consistent with the performance problems described in this issue: https://github.com/virtio-win/kvm-guest-drivers-windows/issues/1482 Has anyone else experienced this issue, or found a way to work around it? Let me know if there's any more information that I could provide that might give some insight into the matter. Kind Regards, Joel McLean https://www.micron21.com/ 1300 769 972 03 9751 7618 0407 888 429 joel.mclean(a)micron21.com Follow us on Twitter and https://m21status.com for important service and system updates. This message is intended for the addressee named above. It may contain privileged or confidential information. If you are not the intended recipient of this message you must not use, copy, distribute or disclose it to anyone other than the addressee. If you have received this message in error please return the message to the sender by replying to it and then delete the message from your computer.

2 3

[qa] Tempest gate is blocked
by Ghanshyam Maan 26 Mar '26

26 Mar '26

Hi all, Tempest gate is currently blocked because tempest-tox-plugin-sanity-check is failing 100%. Please do not recheck until the below fix is merged: - https://review.opendev.org/c/openstack/tempest/+/982305 -gmaan

1 0

[ironic] Hardware type / interfaces removal: SNMP, iRMC, iLO
by Jay Faulkner 26 Mar '26

26 Mar '26

Hey all, We are removing some deprecated drivers in the 2026.2 release. Already posted for removal are the iRMC (Fujitsu) and SNMP driver, which have both been deprecated for removal for a while and are the primary cause of some libraries being version-locked in upper-constraints.txt (sorry Requirements team). I would additionally like to propose we remove the legacy iLO driver as well. Back in 2024.1 release, Ironic added a release note indicating a general plan to deprecate the iLO hardware types with no timeline. In the 2025.2 release, we formally announced the deprecation and added an upgrade check to warn operators using the iLO driver still to migrate off. Now on the horizon of the 2026.2 release, it seems to be time to sunset this driver for good. The proliantutils library it relies on has been unmaintained for a long time and no Ironic community members have access to merge changes on it, and I have a concern that we may be shipping a non-working driver due to this library abandonment. All modern iLO hardware are well-supported by the generic redfish driver. Please scream loudly now if you oppose, or else the iLO driver will be gone this release. Thanks, Jay Faulkner Open Source Developer G-Research OSS

1 0

[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