- openstack-discuss - lists.openstack.org

[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

[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

[manila] No IRC meeting next week (Thu, Nov 27th 2025)
by Goutham Pacha Ravi 20 Nov '25

20 Nov '25

Hello Zorillas and interested Stackers, The Manila team's weekly meeting next week (Nov 27th 2025) has been cancelled due to a lack of quorum. This could be a theme for a few weeks in the remainder of 2025 as we hit local holidays and end-of-the-year holidays observed around the world. Please follow the meeting's wiki page for updates [1]. In the meantime, feel free to chime in on OFTC's #openstack-manila. The next weekly IRC meeting will be on December 4th 2025 at 1500 UTC in #openstack-meeting-alt on OFTC. Thanks, Goutham Pacha Ravi [1] https://wiki.openstack.org/wiki/Manila/Meetings#Next_meeting

1 0

[hacking][all] Expanding set of import exceptions
by Stephen Finucane 20 Nov '25

20 Nov '25

o/ I've been slowly adding type hints to oslo and SDK projects of late as time has allowed. One thing that I've noticed is that strict adherence to hacking's H301 (Do not import more than one module per line) and H303 (Do not use wildcard * import) rules results in both stupidly long groups of imports and overly verbose and difficult to read signatures [1]. I've therefore proposed a change to these rules that exempt some typing-related libraries - collections.abc, types, and typing - from these rules. This is proposed at [2]. As noted there, exceptions already exist for the sqlalchemy and projects' i18n modules for the same reason so this should be nothing new. I am instead bringing this up so projects currently using e.g. 'import typing as ty' imports can pivot to something sooner once this is merged. Cheers, Stephen [1] If you've already started writing a reply about how type hints *themselves* make function signatures more verbose and difficult to read, (a) is your name Sean Mooney and (b) stop right there, go enable an LSP in your editor, then come back to me in a month once you've seen the quality of life improvement hints provide. Then we'll talk 😄 [2] https://review.opendev.org/c/openstack/hacking/+/967719

4 7