- openstack-discuss - lists.openstack.org

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

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

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

03 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

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

[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 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."

3 3

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

03 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

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

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

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

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

02 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

4 5