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

[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

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

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

[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

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

11 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

4 3

[oslo] Proposal to add Ghanshyam Maan as core team
by Daniel Mats Niklas Bengtsson 11 Mar '26

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

2 1

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

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

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

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

1 0

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

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

10 Mar '26

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

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

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

[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

[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