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

[glance][swift][2026.1] Glance fails on image download from Swift
by Dmitriy Rabotyagov 27 Mar '26

27 Mar '26

Hi folks, I am trying to test out Glance configured with Swift backend on 2026.1 prior to the release, and facing some issues. As we are super close to the release, I have decided to pop up with the ML, to ensure it's a "me" problem, and not a generic bug somewhere. So I am using: - Glance installed from SHA 07dd0a203b6883efa66486035c436b92c83da0f3 - glance-store 5.4.0 (according to U-C) - Swift installed from SHA 51b068309a626d2228ab69b5158ee857e96d101d Image upload works quite well [1], image is appearing in Glance and in Swift quite correctly. But whenever I attempt to create an instance from the image, or, basically, just download image with `openstack image save a024ca39-42bc-4a0c-bd34-26209bda4008`,I get Glance WSGI crashing, resulting in 502: root@aio1-utility-container-20f6bf88:/# openstack image save a024ca39-42bc-4a0c-bd34-26209bda4008 Unable to download image: checksum mismatch (sha512): 9a9bce0083a00939ec17c11febbfc767aa211aaa54f51e75c5a8b271a9b5637c77205a518b7a2007cb391d23cceb01e0e4e8d64832317151bc85b734b92a7be0 != a3b1ae48ab757e1e074c33c3159cb3bc749d0119677446b442 c5568eeaf2a4d741d794ca9750e13c3352b7db073d0f9101670f3cbede942df3f5fdb12024aaca <html><body><h1>502 Bad Gateway</h1> The server returned an invalid or incomplete response. </body></html> root@aio1-utility-container-20f6bf88:/# The actual crash and stack trace can be seen here [2]. With that, I can download the image with Swift client without any issues [3], and checksum matches. This result is pretty much reproducible, and I get it constantly in OpenStack-Ansible's CI jobs, for example [4] With that, I have the impression that something goes terribly wrong on the Glance side of things in combination with Swift, as CI jobs using Ceph or File backends are working normally. Given where we are release-wise, I'd love to ask for some help investigating this problem... [1] https://paste.openstack.org/show/bjdhtY2p33L4g0CTTdqH/ [2] https://paste.openstack.org/show/bRhFaEdoJotDngNXBjlB/ [3] https://paste.openstack.org/show/badVIJc0hwqbsy5X3Iv3/ [4] https://zuul.opendev.org/t/openstack/build/0be7ba6d8f854c0a88df9f9e33461d20…

2 5

[openstack-helm] Remove metacontroller and daemonjob-controller
by Vladimir Kozhukalov 27 Mar '26

27 Mar '26

Hi team, I noticed very little interest in maintaining the two charts: metacontroller and daemonjob-controller. If there are no objections I suggest removing them from the OpenStack-Helm project. -- Best regards, Kozhukalov Vladimir

1 1

[horizon] code that depends on openstack_dashboard in Horizon plugins
by Radomir Dopieralski 27 Mar '26

27 Mar '26

There has been recently some discussion, in the context of Horizon releases, about the dependencies Horizon's plugins have on different part of Horizon [1]. It was mentioned there that some plugins import from the openstack_dashboard python package, not just from the openstack_auth and horizon libraries. This is a bit worrying, because as far as I can remember, the idea behind splitting the code into several python packages was to allow the libraries to use the common code that is supposed to be reused, and keep the application-specific code that can change at any moment separate from that. So I went ahead and looked at all the plugins and at what exactly they import from openstack_dashboard: * openstack_dashboard.urls, openstack_dashboard.utils.settings, openstack_dashboard.test.helpers, openstack_dashboard.enabled: tests in almost all plugins * openstack_dashboard.exceptions: mistral-dashboard, charm-openstack-dashboard, watcher-dashboard, openstack-helm, openstack-ansible-os_horizon * openstack_dashboard.api: networking-bgpvpn, tacker-horizon, heat-dashboard, manila-ui, cloudkitty-dashboard, magnum-ui, heat-dashboard, neutron-vpnaas-dashboard, adjutant-ui * openstack_dashboard.policy: tacker-horizon, neutron-fwaas-dashboard, heat-dashboard, blazar-dashboard, trove-dashboard * openstack_dashboard.dashboards.project.instances.utils: trove-dashboard Looking at this list, we can see a few obvious candidates to be moved to either the openstack_auth or the horizon package. The dependency on openstack_dashboard.api is worrying, especially since we are going to rewrite that part entirely to use openstack_sdk and not the deprecated python-openstack-*-client libraries. Perhaps it would not hurt to have the plugins duplicate some of that code, to avoid breaking when we do that. The last one is an outlier, and I'm sure it could be fixed. The test dependencies are a little bit more tricky, because they are mostly copy-pasted code from Horizon's own tests. Some of that code is already deprecated and scheduled for removal in Horizon, the rest should be probably either moved to the horizon package or duplicated. I would be interested to hear from the plugin developers about their opinions on this. Note that my search only included python code. It would be a bit more work to also find any javascript, scss, and template dependencies, if they exist. [1] https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack…

1 0

[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

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/

2 1

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

[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

[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

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

20 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

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

18 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

[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

[docs] Documentation sites are extremely slow
by Eugen Block 18 Mar '26

18 Mar '26

Hi, I'm not sure how long it has been like that, but when I tried to access the documentation yesterday, it took forever to load. And it is the same today, it takes several minutes to load any site, for example: https://docs.openstack.org/cinder/2025.2/admin/ I tried it from different networks, didn't make a difference. Is that a known issue? Thanks, Eugen

5 7

[PTG 2026.2] Scheduled Time Slots for Ironic Sessions
by CID Onyedikachi 17 Mar '26

17 Mar '26

Hello Everyone! Ironic PTG sessions have been scheduled for Monday through Friday, 20 - 24 April, 13:00 - 17:00 UTC in the Mitaka room. If any slot doesn’t work for you, a different time can be arranged. Feel free to reply to this email if a change is needed. -Afonne-CID (cid)

2 1

[cinder][backup] BackupManager.restore_backup() missing 1 required positional argument: 'volume_is_new'
by Eugen Block 17 Mar '26

17 Mar '26

Hi, my environment is: Epoxy on Ubuntu 24.04 package-based installation I'm looking for some clarification regarding this bug report [0]. I don't really understand if it's fixed or not. I was trying to rollback a volume to its backup version when I got this stack trace: Backup service: cinder.backup.drivers.ceph.CephBackupDriver. 2026-03-17 08:37:02.805 1516544 ERROR oslo_messaging.rpc.server [None req-54d97a73-522d-411a-9982-1f6bb0ea905b 89c5dcc8793d4867bae22d50e51e16b3 90c403f317ee47feb0dad58461e76fb1 - - - -] Exception during message handling: TypeError: BackupManager.restore_backup() missing 1 required positional argument: 'volume_is_new' 2026-03-17 08:37:02.805 1516544 ERROR oslo_messaging.rpc.server Traceback (most recent call last): 2026-03-17 08:37:02.805 1516544 ERROR oslo_messaging.rpc.server File "/usr/lib/python3/dist-packages/oslo_messaging/rpc/server.py", line 174, in _process_incoming 2026-03-17 08:37:02.805 1516544 ERROR oslo_messaging.rpc.server res = self.dispatcher.dispatch(message) 2026-03-17 08:37:02.805 1516544 ERROR oslo_messaging.rpc.server ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 2026-03-17 08:37:02.805 1516544 ERROR oslo_messaging.rpc.server File "/usr/lib/python3/dist-packages/oslo_messaging/rpc/dispatcher.py", line 309, in dispatch 2026-03-17 08:37:02.805 1516544 ERROR oslo_messaging.rpc.server return self._do_dispatch(endpoint, method, ctxt, args) 2026-03-17 08:37:02.805 1516544 ERROR oslo_messaging.rpc.server ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 2026-03-17 08:37:02.805 1516544 ERROR oslo_messaging.rpc.server File "/usr/lib/python3/dist-packages/oslo_messaging/rpc/dispatcher.py", line 229, in _do_dispatch 2026-03-17 08:37:02.805 1516544 ERROR oslo_messaging.rpc.server result = func(ctxt, **new_args) 2026-03-17 08:37:02.805 1516544 ERROR oslo_messaging.rpc.server ^^^^^^^^^^^^^^^^^^^^^^ 2026-03-17 08:37:02.805 1516544 ERROR oslo_messaging.rpc.server File "/usr/lib/python3/dist-packages/cinder/utils.py", line 1053, in wrapper 2026-03-17 08:37:02.805 1516544 ERROR oslo_messaging.rpc.server return func(self, *args, **kwargs) 2026-03-17 08:37:02.805 1516544 ERROR oslo_messaging.rpc.server ^^^^^^^^^^^^^^^^^^^^^^^^^^^ 2026-03-17 08:37:02.805 1516544 ERROR oslo_messaging.rpc.server TypeError: BackupManager.restore_backup() missing 1 required positional argument: 'volume_is_new' It's stated that it was fixed in cinder versions 22 and 23, we are on Epoxy (cinder v 26) and still hit that issue. I then manually applied [1] which seems to have fixed the "volume_is_new" issue, at least I can restore volumes now. But I was also wondering why it took so long, and noticed that it doesn't keep the sparseness (although it should according to [2]. Here's the 'rbd du' output from a successfully restored volume: rbd du volumes-ssd/volume-6a9a8497-eacd-490e-be3e-f6dbdf638b5d NAME PROVISIONED USED volume-6a9a8497-eacd-490e-be3e-f6dbdf638b5d@backup.db61467a-5c29-4fca-b393-a1962dc6d2a8.snap.1773736256.760678 40 GiB 4.9 GiB volume-6a9a8497-eacd-490e-be3e-f6dbdf638b5d 40 GiB 40 GiB <TOTAL> 40 GiB 45 GiB I didn't expect that. Could anyone help me understand? Thanks! Eugen [0] https://bugs.launchpad.net/cinder/+bug/2025277 [1] https://review.opendev.org/c/openstack/cinder/+/914775 [2] https://bugs.launchpad.net/cinder/+bug/2007615

1 0

[kolla] Proposing Bertrand Lanson for kolla-reviewers
by Michał Nasiadka 17 Mar '26

17 Mar '26

Hello, I’d like to propose Bertrand (blanson) for being a member of the new kolla-reviewers group in Gerrit. That group is a step entry into being a core member of the project - gives +2 right without workflow. Bertrand has been very active in both code submissions and reviews and has solved some of the Podman issues that we have. If nobody opposes - I’ll add Bertrand in a week from now. Cheers, Michal

2 2

[neutron] bug deputy report for week of 2026-03-09
by Bence Romsics 17 Mar '26

17 Mar '26

Hi Team, we have received the following new bug reports. Sorry for not sending this earlier. Critical: * https://bugs.launchpad.net/neutron/+bug/2144313 ovn-db-sync-util for SB sync crashes with ValueError: driver cannot be None fix merged on master: https://review.opendev.org/q/If9cb2e2d1e8b8479a7fc745e0eba9214b5869ec4 High: * https://bugs.launchpad.net/neutron/+bug/2143837 Neutron-fwaas logging driver breaks fwaas extension fix merged: https://review.opendev.org/q/I2b53029fbd3fcc67ab630bc4927a7845bedc6663 * https://bugs.launchpad.net/neutron/+bug/2143901 FWaaS logging driver is not loaded correctly by the neutron server fix merged on master: https://review.opendev.org/q/I5d413123f48ae644d20311abb529983d1830d2dd * https://bugs.launchpad.net/neutron/+bug/2144307 neutron-ovn-db-sync-util is missing required mechanism drivers to be loaded fix merged: https://review.opendev.org/q/I56b3711dc3ed7676de886295aefc3bba24659b77 Medium: * https://review.opendev.org/c/openstack/neutron/+/979705 Neutron can't parse OVN chassis name if it was added via 'ovn-nbctl' command original fix attempt turned into a doc patch: https://review.opendev.org/c/openstack/neutron/+/979705 Low: * https://bugs.launchpad.net/neutron/+bug/2144371 [OVN] Limit and document the IP+MAC AAP, restricted to VRRPv3 wip patch: https://review.opendev.org/c/openstack/neutron/+/980553 Stable: * https://bugs.launchpad.net/neutron/+bug/2143707 [stable][before 2025.1] fullstack fips jobs broken unassigned Wontfix: * https://bugs.launchpad.net/neutron/+bug/2144524 Neutron API returns all ports globally for admin-scoped requests, unlike Nova which scopes by project Incomplete: * https://bugs.launchpad.net/neutron/+bug/2144312 [OVN] Virtual ports should not update the host ID in the VIF details Other: * https://bugs.launchpad.net/neutron/+bug/2143892 [OVN] Test the creation of a "chassisredirect" port for LSP in routers connected to tunnelled networks unassigned, tracking ticket for new tests to be written * https://bugs.launchpad.net/neutron/+bug/2143895 Migrate policy objects to neutron-lib assigned to Slawek, code move to n-lib * https://bugs.launchpad.net/neutron/+bug/2143812 Router extraroute validation rejects nexthops from other subnets on same external network waiting for reporter feedback Still looking at it: * https://bugs.launchpad.net/neutron/+bug/2144501 NetworkContext excludes dynamic segments, breaking hierarchical binding cleanup Cheers: Bence

1 0

[all][elections][ptl][tc] Combined PTL/TC 2026.2 cycle Election Nominations End
by Ian Y. Choi 17 Mar '26

17 Mar '26

The PTL and TC Nomination period is now over. The official candidate lists for PTLs [0] and TC seats [1] are available on the election website. -- PTL Election Details -- There are 8 projects without candidates, so according to this resolution[2], the TC will have to decide how the following projects will proceed: Adjutant, Masakari, Mistral, Oslo, Requirements, Skyline, Venus, Vitrage There are 2 projects that will have elections: Barbican, Horizon. -- TC Election Details -- The official candidate list is available on the election website[1]. Now begins the campaigning period where candidates and electorate may debate their statements. Polling will start Feb 25, 2026 23:45 UTC. Thank you, [0] https://governance.openstack.org/election/#ptl-candidates [1] https://governance.openstack.org/election/#tc-candidates [2] https://governance.openstack.org/resolutions/20141128-elections-process-for…

3 3

Next Digital Sovereignty WG Meeting
by Kendall Nelson 17 Mar '26

17 Mar '26

Hello Everyone! I hope you enjoyed the bye-week; it's time to vote on the next meeting time <https://beta.framadate.org/polls/8529564824278c0ca549>! The next meeting will take place March 17th, 18th or 19th depending on your responses. You have until March 15th to reply to the poll. As for the other in progress items we have: - Allison is drafting sample stances for us to review and select during the meeting - those drafts will be added to the etherpad <https://etherpad.opendev.org/p/Digital-Sovereignty-WG> before the end of the week. - It doesn't look like anyone has been brave enough to jump in and start the comparison sheet <https://docs.google.com/spreadsheets/d/1XhJoB88pkWf26w1JWuo5KqSTrQicTiTZY14…> nor the best practices guide <https://docs.google.com/document/d/1Pv02JFm58k-hefgSQ0_4fgsWQO0erqe42JRZz6I…> so I will try to add some content ahead of the meeting to get the ball rolling unless someone else gets there first! - We currently have three volunteers for doing thought leadership pieces in this space - are there any other volunteers? - Anyone that volunteered to provide a case study is encouraged to begin that work if it has not already been started as we will be touching on updates during the call as well! Did I miss anything? Any questions? If not, please respond to the poll and we will see each other soon! -Kendall

2 4

[tc][all] OpenStack Technical Committee Weekly Summary and Meeting Agenda (2026.1/R-2)
by Goutham Pacha Ravi 16 Mar '26

16 Mar '26

Hello Stackers, We're two weeks away from the date of the coordinated release of OpenStack 2026.1 "Gazpacho" [1]. Last week, we began tagging release candidates for all deliverables following the "cycle-with-rc" release model. There are a few stragglers [2], but the release team hopes to wrap up soon. These candidate builds should assist the community in testing, finding, and patching any release-critical issues for a timely release on April 01, 2026. It's the last couple of days for the PTL Elections for the 2026.2 cycle [3]. If you are an Active Project Contributor in Horizon and Barbican projects, and an OpenInfra Foundation Individual Member who hasn't voted yet, please do exercise your vote. If you're having trouble finding your ballot, please reach out to election officials via this email list or ping them within #openstack-election on OFTC. In the past week, the OpenStack Technical Committee elected its Chair and Vice Chair. I'll be continuing as Chair, and Michal Nasiadka (mnasiadka) will continue as Vice-Chair. We've refreshed our team liaisons as well: Sylvain Bauza (bauzas) and I (gouthamr) will continue as Vulnerability Management Team (VMT) liaisons, and Amy Marrich (spotz[m]) will be our Election liaison. === Weekly Meeting === The last weekly meeting of the OpenStack Technical Committee was held on March 10, 2026 [4]. For the past release, the TC has been meeting on Tuesdays at 1700 UTC, and hosting a monthly meeting at 0800 UTC, a more friendly time slot for contributors in the Eastern Hemisphere. However, with "daylight savings" changes wrecking our calendars a bit, we've decided to run a poll to re-plan our meeting times and formats closer to the OpenInfra PTG (April 20-24, 2026). In the meantime, we'll be keeping the usual meeting slot on Tuesdays at 1700 UTC, and pausing the APAC friendly meeting temporarily. Talk about timezones being challenging. We revisited leaderless project teams. The governance patches for appointing PTLs to Adjutant, Mistral, Skyline, Requirements and Oslo are up on Gerrit and ready to merge once the election results land. Dmitry Robotyegov (noonedeadpunk) volunteered to kick off the retirement process for Venus and Vitrage. Dr. Jens Harbott (frickler) will propose a resolution to credit core reviewers (code-review +/-2, workflow +1) as contributors in our election process—this would cover cases where a core reviewer can't run as PTL because they were only reviewing and approving changes without any patches of their own. Jeremy Stanley (fungi) will improve the election tooling once a resolution is approved. On the CI front, we've picked up a new tox release that broke things and required temporary pinning in our CI jobs [5]. frickler and noonedeadpunk landed fixes, which prompted a broader conversation about migrating from tox to nox, as OpenDev and Zuul did years ago. nox has its benefits—it uses standard packaging tools rather than reimplementing its own—but switching at this point is a lot of effort. It could be worth exploring as a community goal if there's enough interest. The next meeting of the OpenStack TC is Tuesday March 17, 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 [6]. I hope to see you there. === Governance Proposals === ==== Merged ==== - Add TC chair and vice-chair for 2026.2 | https://review.opendev.org/c/openstack/governance/+/979922 ==== Open for Review ==== - Retire requestsexceptions | https://review.opendev.org/c/openstack/governance/+/979815 - 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 - Appoint Arnaud Morin as PTL for mistral | https://review.opendev.org/c/openstack/governance/+/977344 - 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 - Revert "Revive os_monasca" | https://review.opendev.org/c/openstack/governance/+/974775 === Upcoming Events === - 2026-03-23: KubeCon/CloudNativeCon EU: https://events.linuxfoundation.org/kubecon-cloudnativecon-europe/ - 2026-04-01: 2026.1 "Gazpacho" coordinated release - 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/ 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.1 RCs: https://review.opendev.org/q/topic:%22gazpacho-rc1-deadline%22+(status:open… [3] OpenStack 2026.2 PTL Elections: https://governance.openstack.org/election/ [4] TC Meeting IRC Log, March 10 2026: https://meetings.opendev.org/meetings/tc/2026/tc.2026-03-10-17.00.html [5] Tox pinning fix: https://review.opendev.org/c/openstack/openstack-zuul-jobs/+/979118 [6] TC Meeting Agenda, March 16 2026: https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Next_Meeting

1 0

OpenStack RPMs - Call for packaging volunteers
by Francesco Di Nucci 16 Mar '26

16 Mar '26

Hi all, the RDO Project[0], that provided OpenStack RPM packages through the CentOS Cloud SIG, is switching to a container-based approach due to lack of maintainers.[1] This means *there will be no more RPM packages for OpenStack versions after 2025.1/Epoxy unless new maintainers come up*. *This is a call across the EL and OpenStack communities for volunteer maintainers of RPM build pipelines*. If you're interested you can: * Add your name to the dedicated Etherpad (https://etherpad.opendev.org/p/rdo-volunteers) * Register to the RDO devs mailing list (dev(a)lists.rdoproject.org) and ask for more information No previous experience with packaging/pipelines is required, just willingness to learn /Note: this email is being separately to different mailing lists. If you have subscribed to more than one and recieve it multiple times, sorry for the duplication./ Links [0] https://www.rdoproject.org/ [1] https://lists.rdoproject.org/archives/list/users@lists.rdoproject.org/threa… Francesco, another OpenStack on EL operator -- Francesco Di Nucci System Administrator Compute & Networking Service, INFN Naples Email:francesco.dinucci@na.infn.it

1 0

[ops][keystone]Migration to Epoxy and KeyError: '$6$'
by federica fanzago 16 Mar '26

16 Mar '26

Dear all, we are running an OpenStack deployment Caracal on AlmaLinux 9.7 and we are attempting the upgrade to Epoxy release. Our cloud has been running since 2018, and over the years we have performed several release updates (Rocky-Train-Yoga-Caracal) without modifying the default value for the parameter "password_hash_algorithm" in the keystone.conf file During the update to Epoxy, Keystone shows an error in /var/log/httpd/keystone_wsgi_internal_error.log that seems related to the deprecation of older encryption algorithms 026-03-13 15:31:15.359556 ValueError: Unsupported password hashing algorithm ident: $6$ 2026-03-13 15:31:17.703201 mod_wsgi (pid=32730): Exception occurred processing WSGI script '/usr/bin/keystone-wsgi-public'. 2026-03-13 15:31:17.703935 Traceback (most recent call last): 2026-03-13 15:31:17.703966 File "/usr/lib/python3.9/site-packages/keystone/common/password_hashing.py", line 72, in _get_hasher_from_ident 2026-03-13 15:31:17.703972 return _HASHER_IDENT_MAP[hashed[0 : hashed.index('$', 1) + 1]] 2026-03-13 15:31:17.703994 KeyError: '$6$' In our db there are some passwords starting with "$6$round....". Do you any have suggestions about how to modify the encryption algorithm for these passwords to $2$? Is there a keystone script to perform this migration and fix the error? Thanks, cheers Federica -- Federica Fanzago INFN Sezione di Padova Via Marzolo, 8 35131 Padova - Italy Tel: +39 049.967.7367 --

2 2

[all][infra] releases.openstack.org is down, CI jobs relying on it are failing, hold any recheck
by Yatin Karel 16 Mar '26

16 Mar '26

releases.openstack.org is down for some reason and jobs failing like:- 2026-03-15 22:15:00.754677 | controller | WARNING: Retrying (Retry(total=0, connect=None, read=None, redirect=None, status=None)) after connection broken by 'NewConnectionError('<pip._vendor.urllib3.connection.HTTPSConnection object at 0x771c7273af90>: Failed to establish a new connection: [Errno 111] Connection refused')': /constraints/upper/master 2026-03-15 22:15:00.754693 | controller | ERROR: Could not install packages due to an OSError: HTTPSConnectionPool(host='releases.openstack.org', port=443): Max retries exceeded with url: /constraints/upper/master (Caused by NewConnectionError('<pip._vendor.urllib3.connection.HTTPSConnection object at 0x771c7273b230>: Failed to establish a new connection: [Errno 111] Connection refused')) Need someone from infra to check and bring this server up to unblock the CI. -- Thanks and Regards Yatin Karel

2 1

[requirements][horizon] Requirements freeze exception request
by Radomir Dopieralski 16 Mar '26

16 Mar '26

Hello, I would like to request a requirements freeze exception to bump the version of Django from 4.2.28 to 5.2.12. It is important for Horizon to ship with a version of Django that is security supported, and the security support for Django 4.2.8 ends next month. Django 5.2.12 is a long-term-support release, and will have security support for the next two years [1]. We have been working on making Horizon compatible with Django 5.2 in this release, but the disruption of the gates and the distractions caused by it in the last few weeks prevented us from getting the relevant patches merged on time for the freeze [2]. The patch for requirements is [3] [1] https://endoflife.date/django [2] https://review.opendev.org/c/openstack/horizon/+/973902 [3] https://review.opendev.org/c/openstack/requirements/+/979862 -- Radomir Dopieralski

9 12

[magnum] Magnum Cluster Template Creation Fails 'oslo.utils>=3.33.0' not found
by Shakko 16 Mar '26

16 Mar '26

Hi guys. First time writing here, so i hope i'm respecting every rule and that i chose the right tag. I'm experiencing this reported bug https://bugs.launchpad.net/kolla-ansible/+bug/2142434 when creating a template on my openstack 2025.2 kolla ansible installation. The 'oslo.utils>=3.33.0' distribution was not found, should be the problem. I did checked inside magnum_api container's venv and oslo utils was installed at version oslo.utils-9.1.0 Also tried to update it (now the version is oslo.utils-10.0.0) but nothing changes... So why is this happening? Anyone knows something about it? Any help would be really appreciated.

1 1

[watcher] Core team updates
by Douglas Viroel 13 Mar '26

13 Mar '26

Hi all, Following up on previous Sean's email[1], from Sep 8th 2025, regarding Watcher core team updates, I'd like to propose the following updates for 2026.2 cycle: 1. Core Removals As we start a new release cycle, the watcher core members mentioned in Sean's email for potential removal due to inactivity (*chenker[2], Dan Smith[3], Marios Andreous[4], and Slawek Kaplonski[5]*) will now be removed, effective immediately. I'd like to take this opportunity to thank all of them for their contributions to Watcher over the years. Maintaining an active core team is essential for the health of the project, and in the case of any of these contributors becoming active again in the future, we would welcome proposals to re-add them to the core team. 2. New Core Member Proposal I'd like to propose adding *Alfredo Moralejo (amoralej)* to both the *watcher-core* and *watcher-dashboard-core* groups. He has been consistently contributing to the Watcher project and has demonstrated a solid understanding of the codebase through quality reviews[6][7] and patches. Alfredo provides valuable feedback, helps with manual testing when needed, proactively file new bugs and assist on the bug triage process. I believe he would be a valuable addition to the core team. If there are no objections, the new core additions will be applied right after the next Watcher IRC meeting, next Thursday, Mar 19th, Please feel free to share any feedback or concern around these 2 proposed changes in the core team. Best regards, [1] https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack… [2] https://www.stackalytics.io/?module=watcher-group&release=all&user_id=chenk… [3] https://www.stackalytics.io/?module=watcher-group&release=all&user_id=danms [4] https://review.opendev.org/q/reviewedby:marios.andreou@gmail.com [5] https://www.stackalytics.io/?module=watcher-group&release=all&user_id=slaweq [5] https://www.stackalytics.io/?module=watcher-group&release=all&user_id=amora… [6] https://www.stackalytics.io/?module=opendev.org/openstack/watcher-dashboard… -- Douglas Viroel - dviroel

1 0

[ironic][nova][ptg] Cross-project session around nova-compute startup
by Jay Faulkner 13 Mar '26

13 Mar '26

Hey all, A few releases back we swapped up the model for nova-compute HA in Ironic -- mainly, moved it in line with other nova drivers where the loss of a single nova-compute service takes down a portion of the cloud, but HA is achieved by having other portions of the cloud still available. This model has serious limitations in an Ironic world; including but not limited to: * Use cases around rebuilding into the same physical machine can never be isolated from an outage (including upgrades) * Even with a reasonable number of nodes managed, nova-compute processes managing Ironic nodes can take a long, long time to get online. We're talking 15-20 minutes with reports of even worse in some scenarios. I'd like to improve this story. It's operationally painful to eat a multi-minute long outage for a deployment of code to a server -- and given my use case of in-place rebuilds, there's no amount of aggregation of nodes which can get us clear of this issue. It's also clear that going back to a model which would run multiple nova-compute processes to manage the same machines is too incompatible with the general nova model; so instead I think we can try to tackle a major pain point: the slow startup. Ideas I have thought about to address this include: * Improving how resources are added to placement for Ironic, doing it incrementally from Ironic may reduce the number of calls needed at startup * Improving placement API interfaces to perhaps allow bulk updates, so we aren't doing "N" calls for "N" ironic nodes at startup, as I believe we currently do * Some method of "handoff" between a staged nova-compute service and one that is shutting down, so we can avoid the outage in properly coordinated update scenarios. (I'm not sure this is possible) One thing that's clear to me: I don't have the knowledge to pursue this alone. My hope is that we can work together at the PTG to determine one or more good, potential directions, then put together a spec during the Hibiscus cycle which could be implemented for "I" (not Icehouse :D). As long as we have a commitment from nova cores to perform reviews and help with the design, I should be also to provide resources (myself + maybe others) from the GR-OSS team to help implement it. Thanks! Jay Faulkner Open Source Developer G-Research Open Source Software

1 0

[release] Release countdown for week R-2, Mar 16 - 20
by Elõd Illés 13 Mar '26

13 Mar '26

Development Focus ----------------- At this point we should have release candidates (RC1 or recent intermediary release) for all the 2026.1 Gazpacho deliverables. Teams should be working on any release-critical bugs that would require another RC or intermediary release before the final release. Actions ------- Early in the week, the release team will be proposing stable/2026.1 branch creation for all deliverables that have not branched yet, using the latest available 2026.1 Gazpacho release as the branch point. If your team is ready to go for creating that branch, please let us know by leaving a +1 on these patches. If you would like to wait for another release before branching, you can -1 the patch and update it later in the week with the new release you would like to use. By the end of the week the release team will merge those patches though, unless an exception is granted. Once stable/2026.1 branches are created, if a release-critical bug is detected, you will need to fix the issue in the master branch first, then backport the fix to the stable/2026.1 branch before releasing out of the stable/2026.1 branch. After all of the cycle-with-rc projects have branched we will branch devstack, grenade, and the requirements repos. This will effectively open them up for 2026.2 Hibiscus development, though the focus should still be on finishing up 2026.1 Gazpacho until the final release. Opening up the new development cycle is also a good opportunity to teams to revise their zuul jobs and used nodesets and clean up all unnecessary ones. For projects with translations, watch for any translation patches coming through and merge them quickly. A new release should be produced so that translations are included in the final 2026.1 Gazpacho release. Finally, now is a good time to finalize release notes. In particular, consider adding any relevant "prelude" content. Release notes are targetted for the downstream consumers of your project, so it would be great to include any useful information for those that are going to pick up and use or deploy the 2026.1 Gazpacho version of your project. 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 Előd Illés irc: elodilles @ #openstack-release

1 0

[ci infra] local PyPi cache/mirroring/proxy
by Radomir Dopieralski 13 Mar '26

13 Mar '26

Hello, I don't really have much more than surface experience with our CI infrastructure, but I wanted to start a discussion on a topic that maybe could be picked up by more knowledgeable colleagues. Our tests install a lot of python packages. It almost feels like more than half the time of any test run is spent installing packages. By default, all those packages are being installed from PyPi directly. I wonder if we could gain some advantages by running a local PyPi cache or mirror inside of the CI infrastructure, and making all those tests use it by default for all its package installs. It would: - speed up the downloading of packages, - make tests more resilient in the face of outside network or PyPi outages, - make us better citizens by decreasing the traffic to PyPi and conserving their resources, - give us more control over which packages are available (so, for example, we could easily pin setuptools for all tests, or ban a particular known bad package version, or even do pre-releases of our own packages before we release them on PyPi), Of course nothing is for free, and such a service would require some extra work to set up and maintain. I don't have the experience to be able to tell if the overhead is worth it, but maybe it's something worth considering? Or maybe we are already doing this, and I'm just wasting everyone's time? There is a number of ready to use tools we could utilize for this: https://packaging.python.org/en/latest/guides/index-mirrors-and-caches/#exi… What do you think? -- Radomir Dopieralski

2 2

[neutron] OVN version used in the functional gate job
by Jakub Libosvar 13 Mar '26

13 Mar '26

Hi all, I wanted to bring this topic up for a discussion again. I’ve been working on a Neutron feature [1] for some time, the feature requires the BGP support in OVN. The functional job currently uses a moving OVN branch based on the OVN LTS version - which is 24.03 - almost 2 years old. I tried to change this and requested a patch to switch to using a pinned OVN mostly for two benefits: - we won’t get gate broken if a bad patch is backported to the branch-24.03 - I get the BGP features needed for the work on [1] The patch was denied to keep the policy we set on ourselves - ie. to go with the branch based on the OVN LTS version. The workaround was to skip multiple tests that rely on the OVN changes specific to BGP. This is not ideal as now majority of the functionality is not tested and we’re just waiting for the LTS release, which may bring some surprises. This was a concrete example but if we put it into a more general situation, in Neutron we heavily rely on OVN and its features and any development of a potential feature that requires some work in OVN gets cumbersome because we can’t validate our code against OVN until the point a next OVN LTS version is released, which in the worst case scenario can take up to 2 years. Hence I propose a change and use a pinned hash from the OVN tree that is updated on two occasions: - A next OVN version is released (non-LTS) - We’re developing a feature that relies on bleeding edge OVN - then we pick a good hash and pin to it in the functional job definition (not in the scripts) This would apply solely to the functional tests because tempest jobs can define their own OVN version and unit tests should be isolated from the used OVN version, and only to the master branch - because that is the development branch after all. Such a change brings multiple benefits, we won’t need to skip tests if the required functionality is not present in current OVN version and have the development go smoother. We may uncover issues in OVN early. We will not get a broken gate if a change containing a bug is backported to OVN stable branch. At this point I can’t see any benefit of using the moving LTS branch, but if there is one please bring it up here. Any thoughts on this? Thanks, Kuba [1] https://opendev.org/openstack/neutron-specs/src/branch/master/specs/2025.2/… [2] https://review.opendev.org/c/openstack/neutron/+/961243

5 9

[kolla] Persistent `cannot fork child process` when launching any VM in all-in-one deployment
by Dennis Martin 13 Mar '26

13 Mar '26

Hi everyone, I've been debugging an issue for several weeks and have exhausted the obvious possibilities. I'm hoping the collective expertise here can point me in the right direction. ## Environment - **OpenStack**: Kolla-Ansible 2025.1 (Epoxy), all-in-one deployment - **OS**: Ubuntu 24.04 on a VM (nested virtualization) - **OKD target**: Trying to deploy OKD 4.18, but even a simple Cirros test VM fails ## The Problem Any attempt to create a VM (even `--image cirros --flavor m1.tiny`) fails with: ``` libvirt.libvirtError: cannot fork child process: Resource temporarily unavailable ``` The VM goes straight to `ERROR` state with no useful details in `nova-compute.log` beyond the same error. ## What Works ✅ - OpenStack services are up (`nova-compute`, `neutron`, etc. all healthy) - Can create networks, subnets, routers, keypairs via CLI - Direct `qemu-system-x86_64 -enable-kvm` test succeeds (KVM itself works) - `/dev/kvm` exists with correct permissions - KVM modules loaded (`kvm_intel`), nested virt enabled (`Y`) ## What We've Checked (All Fine) | Check | What We Found | Status | |-------|---------------|--------| | System PID limit (`pid_max`) | 4,194,304 | ✅ OK | | Kernel threads max (`threads-max`) | 722,077 | ✅ OK | | User process limit (`ulimit -u`) | 361,038 | ✅ OK | | Host thread count (`ps -eLf \| wc -l`) | ~111,000 | ✅ OK | | `nova_compute` container `pids.max` | 108,000 | ✅ OK | | `nova_compute` PIDs in container | 27 | ✅ OK | | `nova_libvirt` container `PidsLimit` | `<nil>` (unlimited) | ✅ OK | | AppArmor blocking libvirt | No profiles loaded | ✅ OK | | Host `libvirtd` running | Inactive | ✅ OK | | Libvirt log volume size | 12KB | ✅ OK | | RAM available | 88 GB total, plenty free | ✅ OK | | vCPUs | 32 cores | ✅ OK | ## What We Can't Check (Missing Commands) Inside the `nova_libvirt` container, the `ulimit` command is missing, so we cannot determine: - `nproc` limit inside the container - `nofile` (file descriptor) limit ## What We Haven't Checked - Kernel parameters like `vm.max_map_count` (default is 65530, could this be an issue?) - cgroup v2 limits on the `nova_libvirt` container (Ubuntu 24.04 uses cgroup v2) - `libvirtd` logs inside the container (the log file may not exist or be empty) ## The Ask Has anyone seen this in a Kolla-Ansible all-in-one deployment where all the obvious limits are large but libvirt still refuses to fork? Could it be: 1. A cgroup v2 limit we missed? 2. A kernel parameter that needs tuning (`vm.max_map_count`)? 3. Something else entirely? I'm happy to run any additional diagnostics or provide more logs. Any guidance would be hugely appreciated. Thanks, Dennis

2 1

[kolla-ansible][flamingo][vpnaas] Problem and solution
by Franck VEDEL (UGA) 13 Mar '26

13 Mar '26

2 3

Re: [Devel] OpenStack RPMs
by Neal Gompa 13 Mar '26

13 Mar '26

On Thu, Mar 12, 2026 at 8:08 PM Francesco Di Nucci via Devel <devel(a)lists.almalinux.org> wrote: > > Hi all, > > given that RDO will soon stop releasing RPMs of OpenStack, it has been > suggested on IRC etc that AlmaLinux and Rocky Linux communities might be > interested in building the RPMs instead, is there already a discussion > about it? > I think we'd generally prefer to see AlmaLinux contributors helping out in upstream RDO. If there are folks from the AlmaLinux community interested, please engage with RDO to help them. -- 真実はいつも一つ！/ Always, there's only one truth!

1 0

[kolla] Help debugging cannot fork child process when launching VMs in all-in-one deployment
by Dennis Martin 12 Mar '26

12 Mar '26

Hi Kolla team, I've been troubleshooting an issue for weeks and would really appreciate your insight. *Environment:* - Kolla-Ansible 2025.1 (Epoxy) all-in-one - Ubuntu 24.04 on VM (nested virtualization) - OpenStack services seem healthy (nova-compute, neutron, etc. all up) *The Problem:* Any attempt to create a VM (even a tiny Cirros test VM) fails with: text libvirt.libvirtError: cannot fork child process: Resource temporarily unavailable *What Works:* - ✅ Can create networks, subnets, routers, keypairs via CLI - ✅ Direct qemu-system-x86_64 -enable-kvm test succeeds - ✅ /dev/kvm exists with correct permissions - ✅ KVM modules loaded (kvm_intel), nested virt enabled (Y) *Resource Limits (all seem fine):* - RAM: 88 GB, vCPUs: 32 - pid_max: 4,194,304 - kernel.threads-max: 722,077 - ulimit -u: 361,038 - Total host threads: ~111k (well below limits) *Container-Specific Checks:* - nova_compute: pids.max=108k, Max processes=unlimited, only 27 PIDs running - nova_libvirt: No explicit PidsLimit (<nil>), logs not showing obvious errors - Libvirt volume only 12KB (no runaway logs) - Host libvirtd is inactive (no conflict) *What I've Tried:* - Recreated networks/routers multiple times - Restarted containers - Verified all endpoints are correctly set to VIP (192.168.58.50) - Checked kernel logs – no relevant errors *Full error from nova-compute log:* text libvirt.libvirtError: cannot fork child process: Resource temporarily unavailable Has anyone encountered this in an all-in-one deployment where all obvious limits are huge but libvirt still refuses to fork? Could it be a cgroup v2 limit I'm missing, or something in the libvirt container configuration? Any pointers would be hugely appreciated. Thanks, Dennis

1 0

[Keystone][ldap] Keystone bind request to ldap not able to interpret if the user's password is expired.
by Sharath Ck 12 Mar '26

12 Mar '26

Hi, I have configured Keystone with 389ds as backend. 389ds server is configured with password policy and pwdmustchange is set to true. However on first login attempt from keystone to request token for user in 389ds is resulting in successful bind request. Perhaps, 389ds is providing control ID - control: 2.16.840.1.113730.3.4.4 in the response. But keystone is not able to interpret the control ID and provide a token with full access. Is it not possible for keystone to respond token with minimum scope to only change password? Or any response attribute to specify password is expired and needs to be changed? Kindly help with any configuration that may interpret the password expiry of ldap user and can be used in token response. P.S: configuring user_enabled_attribute to check nsAccountLock will not work as ldap user's password would be expired but not locked. user_enabled_attribute = nsAccountLock user_enabled_mask = 0 user_enabled_invert = true user_enabled_default = true Regards, Sharath

3 3

[tc][ptls] OpenInfra Live: OpenStack 2026.1 'Gazpacho'
by Allison Price 11 Mar '26

11 Mar '26

Hi everyone, As we get closer to the next release date, I wanted to do the bi-annual call for volunteers to talk about the release highlights coming out of OpenStack 2026.1 ‘Gazpacho.’ The plan would be for this episode to be on Thursday, April 2 at 1400 UTC (9am CT). In case you have not seen a past episode, you can check out the format here [1]. If possible, I would like to finalize the lineup by first thing next week so we can promote with ample time. This is always our most popular webinar. If you have any questions, just let me know. Thanks! Allison [1] https://www.youtube.com/watch?v=cdqL6umlM1w

5 5

[dev][ptl][release] Cycle highlights for 2026.1/Gazpacho
by Jeremy Stanley 11 Mar '26

11 Mar '26

Now's the time for merging your 2026.1/Gazpacho release highlights, so if you have something you want to mention then write and push cycle-highlights additions for the corresponding deliverable files in the openstack/releases repository at your earliest opportunity. The OpenInfra marketing machine is getting ready to digest what's at https://releases.openstack.org/gazpacho/highlights.html and put together a press release and package for news outlets. They're interested in whatever you're excited to include, but especially anything related to AI, digital sovereignty, security, or VMware feature parity. Please get your highlights in this week if at all possible! -- Jeremy Stanley

1 1

Ideas to improve contributor and maintainer experience
by Ildiko Vancsa 10 Mar '26

10 Mar '26

Hi OpenStack Community, I’m reaching out to you about some next steps after the metrics and survey analysis for the Flamingo cycle. As we’ve been diving into data[1] and feedback[2] to better understand challenges that contributors and maintainers in OpenStack are facing, we reached the stage to start working with teams on improvement ideas. A few challenges stood out for us, like mismatched expectations caused by incomplete communication or silence, or inconsistencies in where maintainers track priorities and progress and where contributors look for this information. While more people to do reviews and maintenance work is always in need, clear and proactive communication practices can improve maintainer and contributor experience across the board. Below is a summary of the key ideas that Jeremy started to share with teams, to start experimenting with: 1. Make Review Priorities Explicit, and Don’t Forget to Keep Them Up to Date While many teams already document and publicize their review priorities and decision-making processes, the last survey round showed that contributors are often not aware of where to look for this information. Since there’s no single entry point into the community, mentioning the processes and pointing at resources is often helpful, like linking to priority criteria in review comments so contributors understand where their change fits and how they can engage in reprioritization discussions. Transparency here reduces uncertainty and helps contributors plan effectively. In addition, even when a team has a clear process to define, document and track priorities, information can get lost between release cycles. Adding it to the end-of-release tasks to update progress on ongoing items and deal with the ones that didn’t conclude in the cycle ending can improve contributor experience and help with more accurate planning for the upcoming cycle. This also means to check on the incomplete items at the start of the next release cycle and factor in that ongoing work when calculating bandwidth and availability. 2. Proactively Communicate Reviewer Availability It’s very easy to assume that project maintainers are available to do reviews full time, even more seasoned contributors make this mistake from time to time. Clear communication can ease the pressure on maintainers. This can include signals about reviewer bandwidth, upcoming absences, or looking for people who can take on ongoing reviews for some time can significantly reduce ambiguity. When contributors understand expected wait times—and are encouraged to share their own availability—coordination improves and stalled reviews can decrease. 3. Use Clear, Accessible Language Given that English is not the primary language for much of our community, we should avoid excessive acronyms and team-specific jargon. Clear, plain language lowers barriers to entry and reduces avoidable misunderstandings. It also helps new and casual contributors to feel more included and can increase the probability of them sticking around. 4. Develop Contributor and Reviewer Checklists Once the release cycle gets busy, it’s easy to forget about some of the above mentioned new practices before they become a habit. To help overcome that, we are also working on simple checklists to guide reviewers when leaving comments on new or in-progress changes. These will serve as lightweight guardrails for both new and experienced contributors and maintainers to further improve efficiency without added complication or burden. 5. Provide Reusable Review Templates Some of the above practices can result in broader comments in reviews, which can feel like a burden to reviewers and maintainers. We are working on creating response templates for common review scenarios, which you can fine tune for your project and context and then copy and paste into ongoing reviews where applicable. Templates can increase efficiency while reducing the time spent on phrasing review comments and making sure all useful information and resources are shared. Some teams have already been following this practice, which we will use as inspiration. You can also think about templates as a way to get through your review checklist quicker. 6. Publish Case Studies of Successful Contribution Models and Practices Some project teams seem to handle pressure and incoming load better than others, which can serve as inspiration for others to figure out what practices and methods to implement. This also applies to companies who have their employees working upstream, as in some having better practices to support their people than others. We aim to collaborate with teams and companies and teams alike to capture practices that yield better productivity without burnout. Documenting what works as case studies can help project teams and companies to understand how to implement practices in their own context. While we work on refining improvement ideas and sharing additional details we welcome your feedback and help to let us know what worked for you, and what practice didn’t produce the outcome or improvement you and your team hoped for. Some project teams are also experimenting with AI, to use it to speed up code reviews and navigate their tasks easier and more efficiently. While these practices are not yet ready to share widely as standards, OpenInfra community managers are curious to learn about your experience so far! We will schedule a session for the upcoming PTG[3] in April to discuss ideas and next steps further. Best regards, Ildikó [1] https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack… [2] https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack… [3] https://openinfra.org/ptg/

1 0

[openstack][neutron][ovn]Cannot ping VIP without disable port security
by Nguyễn Hữu Khôi 10 Mar '26

10 Mar '26

Hello, I am setting up HA OPNsense on OpenStack, and here are the steps I followed. I successfully configured CARP between two firewall instances, but from a PC in the same subnet as the VIP, I cannot ping the VIP address. When I capture traffic on the master firewall, I can see the ARP request and reply, but on my PC I do not see any reply packets. I have also configured allowed_address_pairs with the VIP address on the member ports, but the VIP only responds when I disable port security. Additionally, I created a port with the VIP address and assigned a floating IP to it. However, it does not work unless I *disable the port admin state*. When I repeatedly refresh the browser (press F5 many times), the traffic is redirected between the two firewall members, which means the connection does not remain persistent on the CARP master. Is there any additional configuration required in OpenStack (Neutron / OVN) to properly support CARP VIPs without disabling port security? Thank you for your assistance. Nguyen Huu Khoi

3 7

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

10 Mar '26

Hello Stackers, Tomorrow (that's 11 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

[Nova][Vms]Persistent I/O Errors in RBD-backed Instances After Compute Node Failure
by Thamanna Farhath 10 Mar '26

10 Mar '26

Hello, We are currently investigating an issue related to OpenStack (2023.1) instances using Ceph RBD storage. However, after further testing in a lab environment we observed that the problem occurs specifically when a compute node goes down or reboots unexpectedly. In this situation, the instances that were running on the affected compute node later experience persistent I/O errors inside the guest OS, even after the compute node comes back online, the instance is usually in a SHUTOFF state, and when we try to start it again, the same I/O errors appear inside the guest. We also attempted instance evacuation to another compute node, but the evacuated instance still shows the same I/O errors inside the guest. We would like to understand the recommended approach in such cases: • What is the best practice to recover RBD-backed instances after a compute node failure when persistent I/O errors appear inside the guest? • Are there any recommended configurations or operational procedures in OpenStack or Ceph to prevent or mitigate this situation? Any suggestions or guidance would be greatly appreciated. Best regards, Thamanna Farhath Disclaimer : The content of this email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to which they are addressed. If you have received this email in error, please notify the sender and remove the messages from your system. If you are not the named addressee, it is strictly forbidden for you to share, circulate, distribute or copy any part of this e-mail to any third party without the written consent of the sender. E-mail transmission cannot be guaranteed to be secured or error free as information could be intercepted, corrupted, lost, destroyed, arrive late, incomplete, or may contain viruses. Therefore, we do not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. The recipient should check this e-mail and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email."

2 1

[tc][all] OpenStack Technical Committee Weekly Summary and Meeting Agenda (2026.1/R-3)
by Goutham Pacha Ravi 09 Mar '26

09 Mar '26

Hello Stackers, We're three weeks away from the date of the coordinated release of OpenStack 2026.1 "Gazpacho" [1]. At the end of this week, all deliverables following the "cycle-with-rc" release model [2] will have published a release candidate. This should assist the community in testing, finding, and patching any release-critical issues for a timely release on April 01, 2026. Looking ahead into the 2026.2 "Hibiscus" release cycle, the OpenStack Technical Committee has updated testing runtimes [3]. We are strongly recommending testing all Python deliverables shipping in the Hibiscus release with Python 3.14; although the common CI template for unit testing will run the job as "non-voting". When we have an operating system available that ships Python 3.14 natively (such as the impending Ubuntu 26.04 LTS), test jobs are expected to become smoother and require less time and resources. PTL Elections are ongoing for Horizon and Barbican [4]. If you are an Active Project Contributor (and an OpenInfra Foundation Individual Member) who hasn't voted yet, please do exercise your vote. If you're having trouble finding your ballot, please reach out to election officials via this email list or ping them within #openstack-election on OFTC. I'd like to congratulate our latest Outreachy Intern, Rose Kimondo, for successfully completing her internship with the OpenStack Manila and Horizon project teams [5]. Rose worked on significant improvements to Manila UI, and Carlos Eduardo da Silva (carloss) and I had the pleasure of mentoring her. If you are aware of opportunities that would retain Rose in our community, please reach out directly to her. === Weekly Meeting === The TC has officially re-formed for the 2026.2 cycle, and our last weekly IRC meeting was held on March 03, 2026 [6]. Our immediate focus was establishing a steady administrative foundation. We'll be electing a new Chair, refreshing our liaisons for the Vulnerability Management, Election and DPL teams, and auditing our weekly meeting time to account for upcoming Daylight Saving Time changes in some parts of the world. Beyond these logistics, we discussed ongoing CI breakages in the requirements repository related to setuptools pinning and a particularly thorny issue where an abandoned dependency is currently blocking Horizon translations [7]. We also discussed "leaderless" project teams. For projects like Masakari, which shows promise in the current market conditions (such as VMware-to-OpenStack migrations), we are exploring a transition to the Distributed Project Leadership (DPL) model to spread the governance load among active contributors. Projects like Vitrage and Venus have seen prolonged inactivity without clear revival interest; we are moving toward their formal retirement. This serves our broader objective of directing community energy toward projects that demonstrate both active maintenance and clear future utility, rather than maintaining technical debt. The next meeting of the OpenStack Technical Committee is today, March 10, 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. === Upcoming Events === - 2026-03-10: OpenInfra Board Meeting: https://board.openinfra.org/ - 2026-03-12: 2026.1 "Gazpacho" Release Candidates due - 2026-03-23: KubeCon+CloudNativeCon EU begins: https://events.linuxfoundation.org/kubecon-cloudnativecon-europe/ - 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/ Thank you very much for reading! On behalf of the OpenStack TC, Goutham Pacha Ravi (gouthamr) [1] 2026.1 "Gazpacho" Release Schedule: https://releases.openstack.org/gazpacho/schedule.html [2] OpenStack release models: https://releases.openstack.org/reference/release_models.html [3] Tested runtimes for OpenStack 2026.2: https://governance.openstack.org/tc/reference/runtimes/2026.2.html [4] OpenStack 2026.2 PTL Elections: https://governance.openstack.org/election/ [5] Rose Kimondo's Outreachy Internship blog: https://rosekimondo.dev/blog/ [6] TC Meeting IRC Log, March 03 2026: https://meetings.opendev.org/meetings/tc/2026/tc.2026-03-03-17.00.html [7] Horizon translations blocked: https://github.com/Zegocover/enmerkar/pull/8 [8] TC Meeting Agenda, March 10 2026: https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Next_Meeting

1 0

[neutron] Bug deputy - week of March 2nd
by Slawek Kaplonski 09 Mar '26

09 Mar '26

Hi, I was bug deputy last week. It was fairly quiet week regarding neutron bugs (there were issues impacting our CI but those were not really Neutron related). ### Critical - https://bugs.launchpad.net/neutron/+bug/2143144 - [networking-sfc] py312 job broken - fixed already by Rodolfo with: https://review.opendev.org/c/openstack/networking-sfc/+/978762 ### High - https://bugs.launchpad.net/neutron/+bug/2143336 - [FT] test_gateway_chassis_least_loaded_scheduler_anti_affinity unstable - **unassigned**, gate failure issue, for now we are skipping this unstable test ### Low - https://bugs.launchpad.net/neutron/+bug/2143050 - Auto allocate service plugin should inherit from ``neutron_lib.services.base.ServicePluginBase`` - fix proposed by Rodolfo: https://review.opendev.org/c/openstack/neutron/+/978898, - https://bugs.launchpad.net/neutron/+bug/2143233 - # [neutron-fwaas] Document: OVN driver has no ``logapi`` implementation - documentation improvement, I assigned it to myself, - https://bugs.launchpad.net/neutron/+bug/2143560 - # Optimization: create a bulk operation for ``_create_port_security_group_binding`` - unassigned, seems a bit like a low-hanging-fruit -- Slawek Kaplonski Principal Software Engineer Red Hat

1 0

[puppet][tc] Future of the project
by Takashi Kajinami 09 Mar '26

09 Mar '26

I had similar discussions earlier in #puppet-openstack several times, but I think it's time to start more formal discussions. As some of you may know, Puppet OpenStack project has been facing several challenges for a few years due to the changes made in the external but related communities, and very honestly speaking, the project is at risk. IMO we have two major challenges now. - RDO officially announced that they discontinue RPM builds and focus on new container-base delivery, based on source-to-build. https://lists.rdoproject.org/archives/list/users@lists.rdoproject.org/threa… Because the primary (and only) architecture we currently support is installation from packages, this means CentOS Stream may no longer be in our support scope. CentOS Stream + RDO has been the primary (and only voting) test architecture because it provides the trunk packages which allow us to test the latest code in development. We could technically switch our primary test architecture to the other platforms like Ubuntu or Debian but this means we can't release our modules in coordinated release timings (because we can implement and test the changes for a new version only after the version is released by these distributions) As we've seen some drastic changes triggered by some initiatives (like eventlet removal) and expect more coming soon, this "lagging-behind" development models can cause several problems like [1]. [1] https://review.opendev.org/c/openstack/puppet-neutron/+/978000 - The upstream puppet has been "dead" after Perforce (who acquired puppetlabs) changed their strategies. OpenVox was created as a fork of puppet, but there are number of core modules such as puppetlabs-apache or puppetlabs-mysql which are not yet forked. I've asked possibility to fork and host these in OpenVox but it was not acceptable due to limited resources the OpenVox community and no real commitment (more specifically speaking, sponsorship) I can provide. There are some works done earlier to replace puppet by OpenVox but it is essentially blocked by the fixes needed in these "abandoned" puppetlabs modules. In addtion, we need to bump versions of our testing platform soon, and I expect these unmaintained modules cause new problems. As afar as I'm aware of, migration to CentOS 10 is completely blocked by "unmaintained puppetlabs-mysql[2], and I expect more for migration to Ubuntu 26.04 or Debian 14 we need in upcoming cycles. [2] https://github.com/puppetlabs/puppetlabs-mysql/issues/1676 So... The situation is getting out of my control and I'd admit that I may soon terminate the project in case the situation is not improved, given my work in the OpenStack community has been all voluntary-based these days. I intend to continue my PTL role of this project for next cycle, so that I can help anyone who would be interested in sustaining the project, but I hope that we get some conclusion and agreement about the future project direction and maintenance during this cycle. Please reply to this in thread or reach me directly (in email or irc) if you are interested in further discussions. Thank you, Takashi -- Takashi Kajinami irc: tkajinam github: https://github.com/kajinamit launchpad: https://launchpad.net/~kajinamit

4 6

[keystone] App Credential reactivation after reconnection is not immediate
by Vincent Godin 08 Mar '26

08 Mar '26

If you create a 24-hour credential application with a non-local user who has a 2-hour time-to-live (default_authorization_ttl), after 2 hours the TTL resets to 0 and the credential application stops working, which is expected. If the user logs back in, there's a waiting period before the credential application becomes functional again, and the same applies if the user want to create a new credential application. I've noticed that if the user leaves a group with member privileges, for example, their app credentials are immediately invalidated. The same behavior should occur when the user logs back in after the TTL expires.

2 1

[Nova][vms]Preventing VM I/O Errors When Ceph OSD Nodes Go Down
by Thamanna Farhath 07 Mar '26

07 Mar '26

Dear Community, We are running OpenStack 2023.1 with Ceph as the backend storage on a 3-node deployment. Recently, we faced a scenario where two of our servers became unresponsive (hung state), and we had to reboot them. During this time, VMs running on the affected compute node started reporting I/O errors inside the guest OS, such as: [ 33.911093] blk_update_request: I/O error, dev vda, sector 229880 op 0x1:(WRITE) flags 0x800 phys_seg 2 prio class 0 [ 33.914953] Buffer I/O error on dev vda1, logical block 319, lost async page write [ 33.914953] Buffer I/O error on dev vda1, logical block 320, lost async page write [ 33.927594] blk_update_request: I/O error, dev vda, sector 229904 op 0x1:(WRITE) flags 0x800 phys_seg 2 prio class 0 It appears that when Ceph becomes unavailable (or quorum is lost), the VMs continue attempting writes, which results in I/O errors at the guest OS level. Our goal: We would like to prevent guest filesystem corruption or I/O errors when Ceph is down. Ideally, we want to: Pause or block writes from active VMs when Ceph storage is unavailable Avoid guest OS filesystem corruption Ensure safer recovery when Ceph services are restored Disclaimer : The content of this email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to which they are addressed. If you have received this email in error, please notify the sender and remove the messages from your system. If you are not the named addressee, it is strictly forbidden for you to share, circulate, distribute or copy any part of this e-mail to any third party without the written consent of the sender. E-mail transmission cannot be guaranteed to be secured or error free as information could be intercepted, corrupted, lost, destroyed, arrive late, incomplete, or may contain viruses. Therefore, we do not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. The recipient should check this e-mail and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email."

4 8

Re: Update on RDO: A Shift to Containers
by Jose Castro Leon 06 Mar '26

06 Mar '26

We are also heavily affected by this change, as all our deployments at CERN rely on it. Moreover, we are early adopters of RDO and now that we are getting into Epoxy release, it just slips away. The deployment model is not something you can easily change. Does it also mean that our el10 users may never have client libraries packaged to use our setups? And following Massimo remark, will the repo be maintained while it's still in supported status in OpenStack? If not, are you implying that we also need to repackage future security updates? Thanks, Jose CERN Cloud Team ________________________________ From: Massimo Sgaravatto <massimo.sgaravatto(a)gmail.com> Sent: Thursday, March 5, 2026 1:40 PM To: Amy Marrich <amy(a)demarco.com> Cc: RDO Developmen List <dev(a)lists.rdoproject.org>; openstack-discuss <openstack-discuss(a)lists.openstack.org>; users(a)lists.rdoproject.org <users(a)lists.rdoproject.org>; Mike Burns <mburns(a)redhat.com> Subject: Re: Update on RDO: A Shift to Containers A non-negligible impact for our deployment :-( So, as far as I understand, no rpms will be released for the F and G releases, correct? Will you keep releasing updated RPMs for the Epoxy release, while it is in the maintained status, or the repo https://mirror.stream.centos.org/SIGs/9-stream/cloud/x86_64/openstack-epoxy/ will not be updated anymore ? Thanks, Massimo On Wed, Mar 4, 2026 at 4:19 PM Amy Marrich <amy(a)demarco.com<mailto:amy@demarco.com>> wrote: Dear RDO Community/Stakeholders, This email provides an important update regarding the RDO project and its future direction which marks a significant change in how RDO content will be delivered. End of RDO RPM Builds Historically, RDO provided RPM-based rebuilds of upstream OpenStack packages. Due to insufficient contributors, the continuous RDO rpm builds that were released through the CentOS Cloud SIG have been officially discontinued as of the Epoxy release. Introducing the New RDO: Container Focus The future of RDO will be focused entirely on containers. This is a pivot from our traditional RPM delivery, as RDO did not previously focus on containers. RDO will be transitioning to Source-to-Image (S2I) builds for service containers. This work will be starting shortly within the <http://github.com/openstack-k8s-operators> github.com/openstack-k8s-operators<http://github.com/openstack-k8s-operators> organization, and these new container builds will essentially be the "new RDO". Timeline and Usage: * This transition work has not yet begun. The timeline is not committed, but the work is currently expected to be available for the Hibiscus release in late 2026. The final delivery location of those images is still to be determined. * These containers are primarily intended to be consumed via the operators provided in the openstack-k8s-operators GitHub organization. * While nothing explicitly prevents these containers from being used elsewhere, this is not currently part of the plan. Community involvement and feedback for broader usage are welcome including within OKD and the okderators. * Please note that the operators in this organization are currently only developed and tested on Red Hat OpenShift Container Platform. Thank you for your understanding and continued support as we make this important shift. We look forward to engaging with the community on this new path forward. Sincerely, Amy

4 3

[all] Another day another CI failure
by Brian Haley 06 Mar '26

06 Mar '26

Hi, Started seeing tox failures in pep8/docs/unit and some other jobs: AttributeError: 'Parsed' object has no attribute 'config_format' Melanie Witt provided some info at [0][1], I opened a bug [2] as it seems like it was caused by a recent commit. I would hold rechecks until someone confirms it's fixed. -Brian [0] https://zuul.opendev.org/t/openstack/builds?job_name=openstack-tox-pep8&ski… [1] https://paste.opendev.org/show/bS87fFXvqOKODTRMllg4/ [2] https://github.com/tox-dev/tox/issues/3866

3 4

[release] Release countdown for week R-3
by Thierry Carrez 06 Mar '26

06 Mar '26

Development Focus ----------------- The Release Candidate (RC) deadline is next Thursday, March 12th, 2026. Work should be focused on fixing any release-critical bugs. General Information ------------------- All deliverables released under a cycle-with-rc model should have a first release candidate by the end of the week, from which a stable/2026.1 branch will be cut. This branch will track the 2026.1 "Gazpacho" release. Once stable/2026.1 has been created, the master branch will be ready to switch to 2026.2 "Hibiscus" development. While the master branch will no longer be feature-frozen, please prioritize any work necessary for completing 2026.1 "Gazpacho" plans. Release-critical bugfixes will need to be merged in the master branch first, then backported to the stable/2026.1 branch before a new release candidate can be proposed. Actions ------- Early in the week, the release team will be proposing RC1 patches for all cycle-with-rc projects, using the latest commit from the master branch. If your team is ready to go for cutting RC1, please let us know by leaving a +1 on these patches. If there are still a few more patches needed before RC1, you can -1 the patch and update it later in the week with the new commit hash you would like to use. Remember, stable/2026.1 branches will be created with this, so you will want to make sure you have what you need included to avoid needing to backport changes from the master branch (which will technically then be 2026.2 "Hibiscus") to this stable branch for any additional RCs before the final release. The release team will also be proposing releases for any deliverable following a cycle-with-intermediary model that has not produced any 2026.1 Gazpacho release so far. Finally, now is a good time to finalize release highlights. Release highlights help shape the messaging around the release and make sure that your work is properly represented. Upcoming Deadlines & Dates -------------------------- RC1 deadline: March 12th, 2026 (R-3 week) 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

OpenStack RPMs
by Francesco Di Nucci 06 Mar '26

06 Mar '26

Hi all, given that RDO will soon stop releasing RPMs of OpenStack, it has been suggested on IRC etc that AlmaLinux and Rocky Linux communities might be interested in building the RPMs instead, is there already a discussion about it? Best regards Francesco Di Nucci -- Francesco Di Nucci System Administrator Compute & Networking Service, INFN Naples Email: francesco.dinucci(a)na.infn.it

1 0

[kolla-ansible][flamingo][horizon] Network creation problem
by Franck VEDEL (UGA) 06 Mar '26

06 Mar '26

Hello everyone, I have a production OpenStack cluster for ESM students running Epoxy, deployed with Kolla-Ansible, and everything is working perfectly. I’m very satisfied with this setup. To prepare for upgrades, I set up a new test cluster in parallel using Kolla-Ansible, but this time with Flamingo. Everything seemed fine until I tried to create a network and its subnet in Horizon. The network is created, but no availability zone is associated with it. As a result, I cannot launch instances on this network. Could this be a change in the new OpenStack installation process that I missed? Or is this a bug? This is the first time I’ve encountered this issue. Is there a parameter that needs to be added in the Horizon override file (_9999-custom-settings.py) to handle this? Thanks in advance for any guidance. Franck VEDEL

2 1

testresources broken with latest fixtures
by Thomas Goirand 06 Mar '26

06 Mar '26

Hi, In its last version of fixtures, the tests folder has been move one directory up. Trying to rebuild testresources, it fails with: ERROR: unittest.loader._FailedTest.testresources.tests.test_test_resource ---------------------------------------------------------------------- ImportError: Failed to import test module: testresources.tests.test_test_resource Traceback (most recent call last): File "/usr/lib/python3.13/unittest/loader.py", line 396, in _find_test_path module = self._get_module_from_name(name) File "/usr/lib/python3.13/unittest/loader.py", line 339, in _get_module_from_name __import__(name) ~~~~~~~~~~^^^^^^ File "/build/testresources-nCTnwj/testresources-2.0.2/testresources/tests/test_test_resource.py", line 18, in <module> from fixtures.tests.helpers import LoggingFixture ModuleNotFoundError: No module named 'fixtures.tests' This isn't seen downstream, as it's still possible to run latest versions of both fixtures and testresources, only testresources unit testing is broken with lastest fixtures, but I don't think it creates any issue for the users of these 2 libs. However, on the distro level, I'm not sure how to fix this... :/ Cheers, Thomas Goirand (zigo)

2 1

[neutron] multicast and allowed address pairs
by Bence Romsics 06 Mar '26

06 Mar '26

Hi Neutrinos, We have a user who discovered that two neutron backends behave differently when it comes to handling multicast traffic. This user runs servers that need multicast for VRRP coordination (the point is multicast, not VRRP). They discovered that with the (no longer upstream supported) OpenDaylight backend, they need to let the multicast traffic through with an allowed address pair. On the other hand, the ml2/ovs backend (here always assuming the ovs firewall driver) allows the multicast traffic by default. If you add the same allowed address pair (for example: {'mac_address': '01:00:5e:00:00:64', 'ip_address': '224.0.0.100'}) as with OpenDaylight, it actually breaks multicast traffic. The traffic breaks even on other servers, affected by the same set of flows installed by ovs-agent. My question is: which backend behaves correctly? And do we need to change anything upstream? Since I found the following upstream history... https://opendev.org/openstack/neutron/src/branch/master/doc/source/admin/co… https://bugs.launchpad.net/neutron/+bug/1889631 ... I believe that ml2/ovs (with the ovs fw driver) behaves correctly when it lets the multicast traffic through by default. However I believe it is a bug that the traffic breaks when the user adds the allowed address pair. But I think it would be pretty pointless to start fixing the traffic itself since we would need to make changes for no effect. Rather we could reject allowed address pairs with multicast IPs/MAC addresses, because that would call the attention of the user that multicast traffic is already handled at a different place (that is the default behavior of the fw driver). I also believe that the OpenDaylight driver is buggy when it does not let the multicast traffic through just like ml2/ovs does. However this is not an upstream problem anymore, since networking-odl is long deprecated. Do you agree in the judgement where the bugs are in this case? The possible upstream change: Do you think we should start rejecting allowed address pairs with multicast IPs/MAC addresses? Plus I guess a doc update for allowed address pairs api-ref is due... If needed, I'm happy to bring this to the drivers meeting. It's 100% that I could attend next Friday (6th of March) and 80% for this Friday (27th of February). Thanks, Bence

3 3

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

05 Mar '26

Hello Argonauts, It's the first week of March, which means that the twice monthly Cinder Festival of Reviews will be held at the end of this week on Friday 6 March. who: Everyone! what: The Cinder Festival of Reviews when: Friday 6 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

Update on RDO: A Shift to Containers
by Amy Marrich 05 Mar '26

05 Mar '26

*Dear RDO Community/Stakeholders,This email provides an important update regarding the RDO project and its future direction which marks a significant change in how RDO content will be delivered.End of RDO RPM BuildsHistorically, RDO provided RPM-based rebuilds of upstream OpenStack packages. Due to insufficient contributors, the continuous RDO rpm builds that were released through the CentOS Cloud SIG have been officially discontinued as of the Epoxy release.Introducing the New RDO: Container FocusThe future of RDO will be focused entirely on containers. This is a pivot from our traditional RPM delivery, as RDO did not previously focus on containers.RDO will be transitioning to Source-to-Image (S2I) builds for service containers. This work will be starting shortly within the github.com/openstack-k8s-operators <http://github.com/openstack-k8s-operators> organization, and these new container builds will essentially be the "new RDO".Timeline and Usage: - This transition work has not yet begun. The timeline is not committed, but the work is currently expected to be available for the Hibiscus release in late 2026. The final delivery location of those images is still to be determined.- These containers are primarily intended to be consumed via the operators provided in the openstack-k8s-operators GitHub organization.- While nothing explicitly prevents these containers from being used elsewhere, this is not currently part of the plan. Community involvement and feedback for broader usage are welcome including within OKD and the okderators.- Please note that the operators in this organization are currently only developed and tested on Red Hat OpenShift Container Platform.Thank you for your understanding and continued support as we make this important shift. We look forward to engaging with the community on this new path forward.Sincerely,* Amy

2 1

[Nova][Tacker][Issue Investigation] API Schema Inconsistency in Nova Microversion 2.100 - Impacting Tacker CI Jobs
by Shivam Shukla 05 Mar '26

05 Mar '26

Hi Nova Team, We are currently facing an issue in Tacker (master branch) caused by a bug in Nova microversion 2.100, where scheduler_hints.group is returned as a list instead of a string in the server GET API response. Problem Statement: The server GET API (microversion 2.100) returns scheduler_hints.group as a list, whereas the API schema requires it to be a string UUID. This type mismatch causes server rebuild operations to fail with a 400 Bad Request error. Root Cause: Nova stores scheduler hints internally using DictOfListOfStringsField, so all values are kept as lists. When microversion 2.100 exposes scheduler hints in the API response, the group field is returned in its raw internal form without being converted back to the string format required by the API spec. Impact: This bug is causing test case failures in Tacker CI jobs, making our pipeline unstable. Detailed information about the bug can be found in the reports linked below: Nova Bug: https://bugs.launchpad.net/nova/+bug/2139275 We'd appreciate your help in reviewing and fixing this bug at the earliest, as it is actively impacting Tacker CI stability. Please let us know if you need any additional details from our side. Thanks in advance for your support! Thanks & Regards, Shivam Shukla (シヴァム・シュクラ) Mobile: +91-9450053922 E-mail: shivam.shukla3(a)india.nec.com The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. It shall not attach any liability on the originator or NEC Corporation India Private Limited or its affiliates. Any views or opinions presented in this email are solely those of the author and may not necessarily reflect the opinions of NEC Corporation India Private Limited or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of the author of this e-mail is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately.

1 0

[requirements][horizon] Requirements freeze exception for XStatic-Font-Awesome
by Tatiana Ovchinnikova 05 Mar '26

05 Mar '26

Hello, I would like to request a requirements freeze exception to unpin XStatic-Font-Awesome and bump it from 4.7.0.0 to 6.2.1.2 [1]. This version doesn't use pkg_resources in build. From Horizon side we have worked around the required changes to use newer versions of the font [2], and after the requirements upgrade to 6.2 the hack can be safely removed. With kind regards, Tatiana [1] 977626: Bump XStatic-Font-Awesome to 6.2.1.2 and unpin it | https://review.opendev.org/c/openstack/requirements/+/977626 [2] 977249: A hack to make Horizon work with Font Awesome 6.2 | https://review.opendev.org/c/openstack/horizon/+/977249

2 1

[requirements][horizon] Requirements freeze exception for selenium
by Tatiana Ovchinnikova 05 Mar '26

05 Mar '26

Hello, I would like to request a requirements freeze exception to unpin Selenium and bump it from 3.141.0 to 4.41.0 [1]. Selenium 3.141.0 no longer works with modern urllib3. It needs to be updated to ensure compatibility with other libraries like urllib3. All required work has been done from Horizon side [2]. As a temporary workaround local upper-constraints.txt was created [3], and the follow up patch to remove it and roll back to global requirements is prepared [4]. With kind regards, Tatiana [1] 978157: Unpin selenium and use latest | https://review.opendev.org/c/openstack/requirements/+/978157 [2] 978177: Upgrade selenium to 4.41.0 | https://review.opendev.org/c/openstack/horizon/+/978177 [3] 978078: Create and use local upper-constraints to avoid Selenium failing | https://review.opendev.org/c/openstack/horizon/+/978078 [4] 978896: Remove local upper-constraints and go back to global one | https://review.opendev.org/c/openstack/horizon/+/978896

2 1

[requirements][sdk] Requirements freeze exception for 'testtools'
by Stephen Finucane 04 Mar '26

04 Mar '26

o/ I would like to request a requirements freeze exception to bump `testtools` from 2.8.4 to 2.8.5, as proposed here [1]. testtools 2.8.5 includes a small type hint fix [2] that resolves pep8 failures currently seen in the gates of a number of SDK deliverables [3][4][5]. It carries effectively zero risk and bumping it would be both easier and safer than updating the affected projects across both master and stable/2026.1 to add `type: ignore` comments or disable the check. Cheers, Stephen [1] https://review.opendev.org/c/openstack/requirements/+/978329 [2] https://github.com/testing-cabal/testtools/compare/2.8.4...2.8.5 [3] https://review.opendev.org/c/openstack/osc-lib/+/978668 [4] https://review.opendev.org/c/openstack/cliff/+/978659 [5] https://review.opendev.org/c/openstack/python-openstackclient/+/978670

2 1

[requirements][sdk] Requirements freeze exception for 'fixtures'
by Stephen Finucane 04 Mar '26

04 Mar '26

o/ I would like to request a requirements freeze exception to bump `fixtures` from 4.3.0 to 4.3.1, as proposed here [1]. As with my earlier testtools request, fixtures 4.3.1 includes a small type hint fix [2] that resolves pep8 failures currently seen in the gates of a number of SDK deliverables. Once again, the bump carries effectively zero risk and bumping it would be both easier and safer than updating the affected projects across both master and stable/2026.1 to add `type: ignore` comments or disable the check. Cheers, Stephen [1] https://review.opendev.org/c/openstack/requirements/+/978871 [2] https://github.com/testing-cabal/fixtures/compare/4.3.0...4.3.1

2 1

[CloudKitty] Core Reviewer Nominations of Juan Larriba and Jaromir Wysogla
by Rafael Weingärtner 04 Mar '26

04 Mar '26

Hello team, I am writing to nominate Juan Larriba (<jlarriba(a)redhat.com>) and Jaromir Wysogla (<jwysogla(a)redhat.com>) as core reviewers for the CloudKitty project. Over the past months they have made significant contributions to the project. We have discussed their nomination in the last bi-weekly meeting, and we will move on with the addition. -- Rafael Weingärtner

1 0

[election][barbican] PTL Candidacy for the 2026.2 Release Cycle
by Mauricio Harley 04 Mar '26

04 Mar '26

Hi, everyone. I would like to continue serving as PTL for Barbican during the 2026.2 cycle. Over the past cycle, I worked to keep the project healthy and aligned with OpenStack's evolving standards. Key achievements include dropping the unmaintained repoze.profile dependency, adopting oslo.middleware's common RequestId implementation, fixing CI nodeset configurations for the Dogtag functional tests, and maintaining release notes across stable branches. I have also ensured alignment with upstream tooling and supported ongoing maintenance across barbican-ui, barbican-tempest-plugin, and openstack-ansible-os_barbican. As the current PTL, I am familiar with the project's codebase, its integration points with other OpenStack services, and our operator community's needs. I am committed to continuing this work, ensuring Barbican remains a reliable secrets management solution, and fostering collaboration with contributors and downstream consumers. I respectfully ask for your support in the upcoming election. Maurício Harley (mharley)

2 1

[neutron][OVN] North South wont work
by Nguyễn Hữu Khôi 04 Mar '26

04 Mar '26

Hello, I have the following issue: My router has an external interface and an internal interface. An instance can ping the router’s external interface, but it cannot ping the external provider network gateway. I am using distributed floating IPs. I created another router using the same provider network, and instances connected to that router can reach the external gateway without any issues. Could you please suggest how I can debug this problem? Openstack Env: 2025.1 Thank you. Regards Nguyen Huu Khoi

2 5

[OSSA-2026-003] OpenStack Vitrage: Remote code execution through Vitrage query parser (CVE-2026-28370)
by Jeremy Stanley 03 Mar '26

03 Mar '26

================================================================= OSSA-2026-003: Remote code execution through Vitrage query parser ================================================================= :Date: March 03, 2026 :CVE: CVE-2026-28370 Affects ~~~~~~~ - Vitrage: <12.0.1, ==13.0.0, ==14.0.0, ==15.0.0 Description ~~~~~~~~~~~ Khalil Lemtaffah (Nokia) reported a vulnerability in the Vitrage query parser. A user allowed to access the Vitrage API may trigger code execution on the Vitrage service host as the user the Vitrage service runs under. This may result in unauthorized access to the host and further compromise of the Vitrage service. All deployments exposing the Vitrage API are affected. Patches ~~~~~~~ - https://review.opendev.org/962671 (2023.1/antelope) - https://review.opendev.org/962713 (2024.1/caracal) - https://review.opendev.org/962712 (2024.2/dalmatian) - https://review.opendev.org/962646 (2025.1/epoxy) - https://review.opendev.org/962658 (2025.2/flamingo) - https://review.opendev.org/962617 (2026.1/gazpacho) Credits ~~~~~~~ - Khalil Lemtaffah from Nokia (CVE-2026-28370) References ~~~~~~~~~~ - https://storyboard.openstack.org/#!/story/2011539 - http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2026-28370 Notes ~~~~~ - The stable/2023.1 branch is unmaintained and will receive no new point releases, but a patch for it is provided as a courtesy. -- Jeremy Stanley OpenStack Vulnerability Management Team https://security.openstack.org/vmt.html

1 0

[manila] Requesting a feature freeze exception for adding Resource Locks in the Manila UI
by Rose Kimondo 03 Mar '26

03 Mar '26

Hi Carlos and Goutham, I would like to formally request a feature freeze exception for the Resource Locks panel for it to be included in this release cycle. My Outreachy internship ends on Friday this week (Match 6th) and I would like to wrap up majority of my work. I would also like to note that adding this feature does not bump the manila API microversion or any add new requirements to the manila-ui project Kind Regards, Rose Kimondo.

3 2

[Nova][vms]Preventing VM I/O Errors When Ceph OSD Nodes Go Down
by Thamanna Farhath 03 Mar '26

03 Mar '26

Dear Community, We are running OpenStack 2023.1 with a 3-node Ceph cluster. Recently, one Ceph nodes became unresponsive, resulting in quorum loss., VMs experienced I/O errors as expected. [ 33.911093] blk_update_request: I/O error, dev vda, sector 229880 op 0x1:(WRITE) flags 0x800 phys_seg 2 prio class 0 [ 33.914953] Buffer I/O error on dev vda1, logical block 319, lost async page write [ 33.914953] Buffer I/O error on dev vda1, logical block 320, lost async page write [ 33.927594] blk_update_request: I/O error, dev vda, sector 229904 op 0x1:(WRITE) flags 0x800 phys_seg 2 prio class 0 We understand this behavior is by design and that Nova does not automatically act based on Ceph health. However, our concern is recovery. In some cases, simply rebooting the VM is not sufficient, and I/O errors persist even after Ceph regains quorum. What is the recommended best practice to safely recover RBD-backed instances in such scenarios? How can we retrieve and restore affected VMs while minimizing filesystem corruption? Disclaimer : The content of this email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to which they are addressed. If you have received this email in error, please notify the sender and remove the messages from your system. If you are not the named addressee, it is strictly forbidden for you to share, circulate, distribute or copy any part of this e-mail to any third party without the written consent of the sender. E-mail transmission cannot be guaranteed to be secured or error free as information could be intercepted, corrupted, lost, destroyed, arrive late, incomplete, or may contain viruses. Therefore, we do not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. The recipient should check this e-mail and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email."

1 0

[tc][all] OpenStack Technical Committee Weekly Summary and Meeting Agenda (2026.1/R-4)
by Goutham Pacha Ravi 02 Mar '26

02 Mar '26

Hello Stackers, We're four weeks away from the date of the coordinated release of OpenStack 2026.1 "Gazpacho" [1]. We're past feature freeze at this point, and project teams are expected to be busy finding and fixing bugs in order to ship our first release candidates in the next couple of weeks. In the past week, five seats on the OpenStack Technical Committee were renewed [2]. I'd like to thank Artem Goncharov (gtema) for the years he spent on the TC. He brought unique perspectives as the PTL of several projects. I'd also like to congratulate Amy Marrich (spotz), Dmitriy Robotyegov (noonedeadpunk), and Dan Smith (dansmith) for being re-elected to the TC. Elections are underway for new PTLs for the Barbican and Horizon project teams. No new governance proposals were merged in the last week. As we wrap up this release cycle, the TC's focus will switch to ensuring a smooth transition between project leaders, filling vacant governance positions within projects, renewing liaisons for cross-project work, and finalizing the tested runtimes for the upcoming release cycle [3]. === Weekly Meeting === The last meeting of the OpenStack Technical Committee was hosted on February 24, 2026, in the #openstack-tc channel on OFTC [4]. We had a candid discussion regarding the size of the TC relative to the community; while there is an argument for shrinking the committee to match candidate interest, our stance is that our workload remains high, and a smaller group would struggle to maintain the necessary oversight without burning out. We took a moment to thank gtema as he ends his term; his expertise in Keystone and the OpenStack SDK has been invaluable, and while he is stepping down from the TC, his "healthy frustration" with bureaucracy will no doubt continue to drive improvements across the projects he leads. We then began our work on stabilizing "leaderless" teams. We noted that Oslo requires a dedicated release liaison to keep our foundational libraries moving. We are hoping that more individuals from the core maintainer team for Oslo participate in the project's formal governance. We discussed a PTL nomination that was blocked due to contribution requirements. The committee seemed supportive of changing how we define contribution. We are going to explore a TC charter change to grant Active Contributor (AC) status to consistent reviewers (+2/+3), recognizing that the "unseen" work of code review is just as vital to project health as code changes themselves. Regarding the gate, a massive update to upper-constraints merged this week, touching over 140 non-OpenStack dependencies. Across project teams, the immediate priority was "de-borking" stable branches due to these changes and monitoring for regressions on the "master" branches to ensure the 2026.1 release remains stable. The next meeting of the OpenStack Technical Committee is today, March 3, 2026. This meeting will be hosted in the #openstack-tc IRC channel on OFTC. Please find the agenda on the meeting's wiki page [5]. I hope to see you there. === Upcoming Events === - 2026-03-10: OpenInfra Board Meeting: https://board.openinfra.org/ - 2026-03-12: 2026.1 "Gazpacho" Release Candidates due - 2026-03-23: KubeCon+Cloud Native Con EU begins: https://events.linuxfoundation.org/kubecon-cloudnativecon-europe/ - 2026-04-20: OpenInfra PTG begins: https://openinfra.org/ptg/ Thank you very much for reading! On behalf of the OpenStack TC, Goutham Pacha Ravi (gouthamr) [1] 2026.1 "Gazpacho" Release Schedule: https://releases.openstack.org/gazpacho/schedule.html [2] OpenStack TC: https://governance.openstack.org/tc/#current-members [3] Tested runtimes for 2026.2: https://review.opendev.org/c/openstack/governance/+/976691 [4] TC Meeting IRC Log, February 24, 2026: https://meetings.opendev.org/meetings/tc/2026/tc.2026-02-24-17.00.html [5] TC Meeting Agenda, March 03, 2026: https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Next_Meeting

1 0

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

02 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 __February 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. We have a packed agenda for this call: - OpenStack HA architectures with guest attendee Tyler Stachecki - How to do OpenStack Backups? - How do people automate their clouds? - Update on Ops Radio Hour Survey results 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 February 27th! Bets Regards, Ildikó [1] https://wiki.openstack.org/wiki/Operations/Meetups

1 1

[neutron] Bug deputy report (week starting on February 23)
by Elvira Garcia Ruiz 02 Mar '26

02 Mar '26

Hi folks! Here is the list of bugs reported for Neutron last week. Most of this week's higher-priority changes are related to FT and Tempest. Critical ---------- - https://bugs.launchpad.net/neutron/+bug/2142679 test_dns_integration fails with testtools 2.8+ due to removed try_import Fix proposed and merged by Rodolfo: https://review.opendev.org/c/openstack/neutron-tempest-plugin/+/977958 High ------- - https://bugs.launchpad.net/neutron/+bug/2142487 [FT] `test_patch_port_ofport` test unstable Unassigned - https://bugs.launchpad.net/neutron/+bug/2142484 [FT] `test_bgp_extension_missing_bgp_peer_bridges` test unstable Unassigned - https://bugs.launchpad.net/neutron/+bug/2142659 [whitebox-neutron-tempest-plugin] Errors when executing the unit tests locally Assigned to Rodolfo. Fix proposed: https://review.opendev.org/c/x/whitebox-neutron-tempest-plugin/+/977946 - https://bugs.launchpad.net/neutron/+bug/2142669 [OVN] ML2/OVN is missing ``ip_allocation`` extension Assigned to Rodolfo. Fix proposed: https://review.opendev.org/c/openstack/neutron/+/977961 Medium ----------- - https://bugs.launchpad.net/neutron/+bug/2142846 [neutron-fwaas] The "firewall_drivers" entry point should also have "ovn" defined Unassigned Low ------ - https://bugs.launchpad.net/neutron/+bug/2142652 Define a reasonable default value for the OVN FDB aging and removal limit Assigned to Rodolfo. Fix proposed: https://review.opendev.org/c/openstack/neutron/+/977984 - https://bugs.launchpad.net/neutron/+bug/2142833 Lack of consistency in the log messages for the OVN maintenance methods Unassigned - https://bugs.launchpad.net/neutron/+bug/2142834 Improve `check_global_dhcp_opts` method Assigned to Rodolfo. Fix proposed: https://review.opendev.org/c/openstack/neutron/+/978182 - bugs.launchpad.net/neutron/+bug/2142840 Method ``network_segments_exist_in_range`` to use a specific SQL query Assigned to Rodolfo. Fix proposed: https://review.opendev.org/c/openstack/neutron/+/978187 Best regards! Elvira

1 0