- openstack-discuss - lists.openstack.org

[qa] devstack & hacking core member updates
by Ghanshyam Maan 24 Nov '25

24 Nov '25

Hello everyone, I would like to propose the following updates to the devstack and hacking project core member list: Devstack: - Adding gibi in devstack core. He has been fixing and helping in devstack for a long time. Hacking: - Adding stephenfin and sean-k-mooney in the hacking core members list. Both have a good understanding of hacking projects and helping there on a need basis. - Frickler and I are part of the hacking core, but via included groups. I will be moving both to the core member list explicitly. Feel free to provide your feedback. If there are no objections by this Friday (21st Nov), I will update the gerrit group. -gmaan

2 2

[tc][horizon]Request for guidance on improving Python PTI doc to include pytest for Horizon plugins testing
by Chandan Kumar 24 Nov '25

24 Nov '25

Hello TC, We are writing to seek your guidance regarding the Python testing standards (PTI) as they relate to Horizon plugins. The current integration tests of the watcher-dashboard project (the Horizon plugin for OpenStack Watcher) are broken due to integration code changes in the Horizon integration suite. We are currently working on rewriting the watcher-dashboard integration tests. We noted that the Horizon project itself has developed a robust set of reusable, pytest-based integration tests, fixtures, tox targets and zuul job[1]. We also see that other plugins, like manila-ui, are already reusing these pytest fixtures.[2]. Several other projects within the OpenStack ecosystem (such as skyline-apiserver, rally, and projects under the Airship and StarlingX namespaces) are already using pytest. This presents a conflict for the Watcher team. The official Python PTI states that tests should be written using the Python stdlib unittest module[3]. The Watcher team advocates for adhering to the Python PTI and using unittest. Our main watcher project uses unittest, and we prefer to maintain this standard for consistency and PTI compliance in watcher-dashboard. This topic came up during watcher PTG discussion[4]. This leaves us with a dilemma: - Follow the Python PTI: This aligns with the PTI and our team's standards but requires us to ignore Horizon's reusable pytest tests and build our own testing framework from scratch, duplicating effort. - Follow the parent project (Horizon) to use pytest to reuse their fixtures. This would be more efficient but appears to violate the Python PTI and creates inconsistency with our main project. - Do we want to improve Python PTI documentation to include pytest usage? We just need guidance on this topic. Links: [1]. https://github.com/openstack/horizon/tree/master/openstack_dashboard/test/s… [2]. https://github.com/openstack/manila-ui/tree/master/manila_ui/tests/selenium [3]. https://github.com/openstack/governance/blob/master/reference/pti/python.rs… [4]. https://etherpad.opendev.org/p/watcher-2026.1-ptg#L404 With Regards, Chandan Kumar

10 22

[kolla] Cancelling weekly meeting on 26th Nov 2025
by Michał Nasiadka 24 Nov '25

24 Nov '25

Hello Koalas, We need to cancel the weekly meeting this week due to unavailability of key participants (including me). See you on the meeting 3rd of Dec. Cheers, Michal

1 0

[Neutron][VPNaaS] Multiple tunnels per IPSec Service
by Shubham Yadav 24 Nov '25

24 Nov '25

Hello OpenStack Community, I'm working with OpenStack VPNaaS (using strongSwan as the backend driver) and have a question about tunnel configuration capabilities. *Current Setup:* OpenStack VPNaaS with strongSwan driver (StrongSwanDriver) Single VPN Service (gateway) with multiple IPSec Site Connections Each connection targets different remote peers with distinct subnets *Configuration Details:* VPN Service: Connected to a single router Multiple IPSec Site Connections under the same VPN Service: Connection 1: To MY office (10.10.100.0/24) via peer 68.x.y.34 Connection 2: To Rackspace (172.24.60.0/22) via peer 184.n.p.53 Shared IKE and IPSec policies across connections Local endpoint groups covering multiple subnets (192.168.0.0/24, 10.43.0.0/16) *Question:*Is it supported/recommended to have multiple IPSec Site Connections under a single VPN Service? I understand this creates multiple tunnels from the same OpenStack router to different remote peers. *Current Issue:*One of my connections shows "PENDING_CREATE" status while the other is "ACTIVE". I'm trying to determine if this is: A configuration issue on my end A limitation of having multiple tunnels per VPN service A strongSwan-specific behavior in the OpenStack context *Specific Questions:* Does VPNaaS officially support multiple IPSec connections per VPN Service? Are there any known limitations or best practices when using multiple tunnels? Should each remote site have its own dedicated VPN Service instead? I've checked the documentation but couldn't find clear guidance on multi-tunnel scenarios. Any insights from the community would be greatly appreciated. *Environment:* OpenStack version: 2024.2 Dalmatian Neutron VPNaaS with strongSwan backend Kubernetes-deployed OpenStack (OpenStack-Helm) Thank you for your time and assistance! Best regards, Shubham

2 1

[openstack-ansible][rabbitmq] Repository change from ppa1 to deb1 for Ubuntu/Debian
by Dmitriy Rabotyagov 23 Nov '25

23 Nov '25

Hi folks, Recently RabbitMQ has changed a repository URL for RabbitMQ and Erlang packages for Ubuntu and Debian. We were using ppa1.rabbitmq.com for all our stable branches, which used to work nicely until recently. With that being said, all existing users need to update their configuration, to use a new repository. For that: * Download GPG key to your deploy host (the one referenced on https://www.rabbitmq.com/docs/install-debian) curl -1sLf https://keys.openpgp.org/vks/v1/by-fingerprint/0A9AF2115F4687BD29803A206B73… -o /etc/openstack_deploy/pki/rabbitmq.gpg * Create /etc/openstack_deploy/group_vars/rabbitmq_all.yml with content: rabbitmq_repo_url: https://deb1.rabbitmq.com/rabbitmq-server/{{ ansible_facts['distribution'] | lower }}/{{ ansible_facts['distribution_release'] | lower }} rabbitmq_erlang_repo_url: https://deb1.rabbitmq.com/rabbitmq-erlang/{{ ansible_facts['distribution'] | lower }}/{{ ansible_facts['distribution_release'] | lower }} rabbitmq_gpg_keys: - file: /etc/openstack_deploy/pki/rabbitmq.gpg This should fix all existing deployments, while we are proposing and backporting patches for all maintained branches. So a proper fix is expected with the next bugfix release.

2 1

[tacker] Cancelling weekly IRC meeting
by Yasufumi Ogawa 23 Nov '25

23 Nov '25

Hi team, Due to a holiday in Japan and most of team members aren't join, I'm cancelling meeting this week. Regards, Yasufumi

1 0

[ops][largescale-sig][scientific-sig][publiccloud-sig] Ops Radio Hour on November 21, 2025
by Ildiko Vancsa 22 Nov '25

22 Nov '25

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 __November 21st, 2025 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 had a great discussion at the last meeting about how to refactor Ops-related activities - See Thierry's email for initial details: https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack… - Meeting notes from October 31st: https://etherpad.opendev.org/p/openstack_ops_radiohour This upcoming call is a great opportunity to discuss and take next steps towards a more cohesive way for Ops folks to gather, discuss challenges and possible solutions, and onboard new operators and users to the community! 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 November 21st! Bets Regards, Ildikó [1] https://wiki.openstack.org/wiki/Operations/Meetups

1 1

[nova][libvirt][qemu] Windows 11 Nested Virtualization Boot Loop on OpenStack (Emerald Rapids Hosts)
by Hai Pham Thanh 21 Nov '25

21 Nov '25

Hi community, We would like to report an issue we are encountering with nested virtualization on Windows 11 instances running on OpenStack. On our OpenStack platform, a Windows 11 VM becomes unable to boot after enabling Virtual Machine Platform/Hyper-V inside the VM and performing a hard reboot (VM does not show a BSOD but fails to boot into the OS and gets stuck in a boot loop in Tianocore logo). This issue does not occur on Windows 10 under the same conditions. System: * Compute node CPU: Intel Xeon Gold 6538Y+ (Emerald Rapids) with nested virtualization is enabled. * OpenStack 2024.2 * libvirt 8.0.0 * QEMU API 8.0.0 * QEMU hypervisor 6.2.0 Initially, our Nova CPU configuration was: * cpu_mode=host-model * cpu_model_extra_flags=+vmx,-hypervisor,-xsaves According to virsh dumpxml, host-model maps to Icelake-Server. We tested several cpu_mode=custom configurations and observed the following: * cpu_models=Icelake-Server-noTSX → error (boot loop) * cpu_models=Icelake-Server → error (boot loop) * cpu_models=Broadwell-noTSX-IBRS → works * cpu_models=Cascadelake-Server-noTSX → works The working models correspond to the Preferred CPU models recommended by QEMU: https://qemu-project.gitlab.io/qemu/system/qemu-cpu-models.html#preferred-c… We would like to ask: 1. Has anyone encountered this issue with Windows 11 + nested virtualization on Icelake/Emerald Rapids hosts? 2. Are there known root causes explaining why newer CPU models fail while preferred (older) models work? 3. Is there a recommended fix other than switching to a preferred older CPU model? Best regards, Hai Pham

4 5

[kolla-ansible][firewalld] Initializing firewall rules for new services
by Jonathan Proulx 21 Nov '25

21 Nov '25

Hi All, Continuing to run through my expoy testing depoly I enabled firewalld management (I think) with: disable_firewall: "false" enable_external_api_firewalld: "true" After predeplying firewalld on the control nodes and adding the public IP interface and an ssh allow rule (and a few other internal allows for $REASONS). This seemed to work for the services I had deployed, but when installing a new service (magnum for example) the API port 9511 is listening on the controllers but blocked externally. There doesn't seem to be a firewall or firewalld tag, is there something else I need to poke? Thanks, -Jon -- Jonathan Proulx (he/him) Sr. Technical Architect The Infrastructure Group MIT CSAIL

1 0

[Nova] Nova bug triage follow-up & volunteer roster proposal
by René Ribaud 21 Nov '25

21 Nov '25

Hi everyone, Following our recent discussions about improving our upstream bug triage process, here’s a *Goal:* Improve bug follow-up and make sure each reported issue gets attention, while keeping the workload balanced across contributors. *Proposed process:* 1. Create a list of volunteers interested in helping with bug triage. 2. Each week, Uggla will distribute a few bugs (no more than 3 per person) to the volunteers’ group for review and follow-up. 3. During the upstream meeting, we’ll briefly check if a *dedicated session* is needed to discuss any specific bugs. 4. If needed, we’ll schedule a *Q&A session every two weeks* (or less frequently if not required). 5. If not, we’ll simply handle questions or updates directly within the upstream meeting. The dedicated session could take place right after the upstream meeting. Please add your name to the Etherpad below if you’d like to volunteer: https://etherpad.opendev.org/p/nova-bug-triage-roster Thanks everyone for your help keeping our bug list healthy and up to date! Cheers, René

2 1