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

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

13 Mar '26

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

1 0

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

13 Mar '26

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

1 0

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

12 Mar '26

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

3 3

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

11 Mar '26

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

5 5

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

11 Mar '26

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

1 1

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

10 Mar '26

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

1 0

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

10 Mar '26

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

3 7

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

10 Mar '26

Hello Stackers, Tomorrow (that's 11 March) the bi-weekly Public Cloud SIG meeting will be held again. The publicly available video meeting will be conducted from 08:05 hrs UTC (09:05 hrs CET) until 08:55 hrs UTC (09:55 hrs CET) here: https://meetpad.opendev.org/publiccloud-sig Additional information to be found on https://wiki.openstack.org/wiki/PublicCloudSIG See you tomorrow! Cheers, Kees __ Kees Meijs BICT Nefos Cloud & IT <https://nefos.com/contact> Nefos IT bv Burgemeester Mollaan 34a 5582 CK Waalre - NL kvk 66494931 +31 (0)88 2088 188 <tel:+31882088188> nefos.com <https://nefos.com/contact> The information contained in this message is intended for the addressee only and may contain classified information. If you are not the addressee, please delete this message and notify the sender; you should not copy or distribute this message or disclose its contents to anyone. Any views or opinions expressed in this message are those of the individual(s) and not necessarily of the organization. No reliance may be placed on this message without written confirmation from an authorised representative of its contents. No guarantee is implied that this message or any attachment is virus free or has not been intercepted and amended. General terms and conditions ("The NLdigital Terms") apply to all our products and services.

1 0

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

10 Mar '26

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

2 1

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

10 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