- openstack-discuss - lists.openstack.org

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

12 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

4 3

[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

[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

1 0

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

11 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 11 Mar '26

11 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