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

[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

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

04 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

4 7

[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 04 Mar '26

04 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

April 2026 PTG Team List Announcement
by Kendall Nelson 03 Mar '26

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

1 0

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

03 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