- openstack-discuss - lists.openstack.org

[nova] limiting number of attached devices
by Pavlo Shchelokovskyy 07 Oct '25

07 Oct '25

Hi all, we've recently faced a peculiar issue with one of the users, namely: - fat VM with 100 cores - virtio-net multiqueue set up for the VM (`hw:vif_multiqueue_enabled`) - quite a number of NICs attached. On an attempt to attach yet another NIC (~20th), instance crashes with specific error message in the qemu log ``` qemu-system-x86_64: ../../accel/kvm/kvm-all.c:1754: kvm_irqchip_commit_routes: Assertion `ret == 0' failed. ``` After debugging, we believe that what's happening is we are hitting an intrinsic limit of IRQs in a KVM guest ( `KVM_MAX_IRQ_ROUTES 4096` here https://github.com/torvalds/linux/blob/master/include/linux/kvm_host.h#L2175 ). With multiqueue and this number of vCPUs, each new NIC adds ~200 interrupts in the guest, so with some other system ones and some more devices already present, at some point, adding one more NIC overflows this current limit. In this particular case, the problem is exaggerated by the fact that what's requesting the new NIC attachment is some sort of CNI-like automation inside the guest, reacting on some external events (like another k8s node going down and pods being migrated). This got me thinking - should nova be able to somehow hard-limit the number of attached devices to a VM? I do not think nova should be "counting the IRQs" per se, as there are things outside that nova does not necessarily know (like what and how many actual devices a given qemu machine type creates inside the guest). But having some knob on a user side, for example a special metadata set on the instance, or at least an extra spec property for the flavor, could possibly suffice in this case. I'm eager to hear your thoughts on this, please chime in with any ideas on how to prevent such self-destructing instances :-) Best regards, -- Dr. Pavlo Shchelokovskyy Principal Software Engineer Mirantis Inc www.mirantis.com

1 0

[kolla][kolla-ansible] Managing Object Storage Backend via Kolla-Ansible
by Sara khosravi 07 Oct '25

07 Oct '25

Hello everyone, We’re currently using Kolla-Ansible stable/2024.1 to manage our OpenStack deployment, including both core services and the Swift object storage backend. aiming to manage both core OpenStack services and the object storage service through a unified lifecycle management tool. We understand that handling large volumes of data can impact the performance of other services. To mitigate this, we've separated the data path entry points that could become bottlenecks into dedicated and distinct host groups—load balancer and Swift proxy. Specifically, we've introduced two host groups: one for the secondary load balancer (serving as the initial entry gateway) and another for the Swift proxy services. 🔹 **Key Point 1:** We've decoupled the Swift proxy from other OpenStack API services. As a result, the load balancer for Swift must also be isolated from the main load balancer handling other APIs. 🔹 **Key Point 2:** The Swift service registers itself with the existing Keystone service. Depending on the configuration: - If `second_loadbalancer` is enabled, Keystone will expose the load balancer VIP as the endpoint for object storage. - If `second_loadbalancer` is disabled, Keystone will use the direct API address of the Swift proxy. We've attached an architectural diagram to illustrate the overall setup. We’d love to share this approach and welcome any feedback or suggestions from the community. Our broader goal is to eliminate the barriers to managing both storage and OpenStack services simultaneously within a single deployment and through a unified tool. Thanks in advance for your insights!

2 1

[tc][all] OpenStack Technical Committee Weekly Summary and Meeting Agenda (2026.1/R-25)
by Goutham Pacha Ravi 06 Oct '25

06 Oct '25

Hello Stackers, We're officially in the 2026.1 "Gazpacho" development cycle [1]. Congratulations on the successful and timely release of OpenStack's 32nd release: 2025.2 "Flamingo". For more information on the release, the OpenInfra Foundation staff have pieced together a release highlight on the OpenStack website [2], and project maintainers spoke about the release on OpenInfra Live [3] last week. In the past week, as our focus slowly began shifting between release boundaries, the OpenStack Technical Committee welcomed a new Vice-Chair, Michał Nasiadka (mnasiadka). We're exploring options for an alternate weekly meeting timing that could be friendly to our contributors in the Eastern Hemisphere. mnasiadka will be leading these meetings, while we still hope to continue a good cadence on our existing weekly meetings. I'll bring you more details about this change as we finalize the details. We're also actively planning sessions for the upcoming OpenInfra PTG. The OpenStack TC etherpad is available for you to propose topics [4]. Please feel free to add a topic along with your nick and timezone so we can coordinate a final schedule during the PTG week, avoiding as many conflicts as possible. In the past week, the TC appointed Felipe Reyes (freyes) as the PTL to the OpenStack Charms project [5]. We extended the "inactive" status of the Monasca team through the 2025.2 release cycle, and a decision on its retirement is imminent. There are similar proposals regarding other teams that had no PTL nominees in this past round of elections. === Weekly Meeting === The TC weekly meeting on September 30th 2025 [6] focused primarily on addressing leaderless projects and filling key TC roles. The committee proposed to mark both the Venus and Vitrage project teams as "inactive" and notify the openstack-discuss mailing list, as neither team has found a new Project Team Lead (PTL) so far. The Gerrit activity on both these projects has shown a slowdown, which could either mean maturity and stability, or lack of maintenance. Continuous integration system jobs are failing for some of the deliverables; therefore, they're not release-worthy for now. If maintenance and development activity does not resume over the 2026.1 release cycle, the deliverables will be retired. We discussed the need for TC liaisons to the Freezer, Oslo, Release Management, and Requirements projects. Sylvain Bauza (bauzas) and I will continue being the OpenStack VMT liaisons. We noted progress on the recent community engagement regarding Skyline's health and patch merging [7], and discussed plans to mentor one or more new core maintainers, and possibly hold a dedicated slot at the upcoming PTG (Project Team Gathering) to encourage further engagement. The TC is running an internal poll to find a preferred time slot and format (video vs. IRC) for future meetings, including a request for a slot that better suits EU and APAC time zones. The next meeting of the OpenStack TC is on October 7th 2025. This meeting will be hosted on Meetpad and IRC simultaneously. Please find the meeting's agenda and joining details in the wiki [8]. I hope you'll be able to join us. === Governance Proposals === ==== Merged ==== - Add 2026.1 TC chair and vice-chair | https://review.opendev.org/c/openstack/governance/+/962614 - Extend Monasca's inactive state | https://review.opendev.org/c/openstack/governance/+/959392 - Appoint Felipe Reyes as PTL for OpenStack Charms | https://review.opendev.org/c/openstack/governance/+/962121 - pti: Remove reference to 'python setup.py' | https://review.opendev.org/c/openstack/governance/+/962920 - pti: Update to reference pyproject.toml | https://review.opendev.org/c/openstack/governance/+/962921 ==== Open For Review ==== - Retire Monasca project | https://review.opendev.org/c/openstack/governance/+/953671 - Require declaration of affiliation from TC Candidates | https://review.opendev.org/c/openstack/governance/+/949432 - Mark Vitrage project-team inactive | https://review.opendev.org/c/openstack/governance/+/963227 - Mark Venus project-team inactive | https://review.opendev.org/c/openstack/governance/+/963228 === Upcoming Events === - 2025-10-17: OpenInfra Summit, Paris-Saclay: https://summit2025.openinfra.org/ - 2025-10-27: OpenInfra PTG: https://openinfra.org/ptg/ - 2025-10-04: OpenInfra Board meeting: https://board.openinfra.org/ 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] 2025.2 "Flamingo" release page: https://www.openstack.org/software/openstack-flamingo [3] OpenInfra Live previewing the 2025.2 "Flamingo" release: https://www.youtube.com/watch?v=cdqL6umlM1w [4] OpenStack TC etherpad for 2026.1 "Gazpacho" PTG: https://etherpad.opendev.org/p/oct2025-ptg-os-tc [5] Appointing PTL for OpenStack Charms: https://review.opendev.org/c/openstack/governance/+/962121 [6] TC Meeting IRC Log, Sep 30th 2025:https://meetings.opendev.org/meetings/tc/2025/tc.2025-09-30-17.00.html [7] Skyline Maintenance discussion: https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack… [8] TC Meeting Agenda, Oct 7th 2025: https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Next_Meeting

1 0

[ironic][power] Anyone using PReP partitioning support?
by Julia Kreger 06 Oct '25

06 Oct '25

Greetings Power folks! The Ironic project is curious if anyone is using PReP partitioning support? Specifically Ironic has long had a code path to manage creation of the PReP partition for booting power hardware as part of the partition image path code, but as time has gone on we're unsure if anyone is actively using this code path on newer versions of Ironic, coupled with the general decline of partition image usage. If anyone is using Power with newer versions of Ironic, please let us know if you're using partition images with Ironic, thus using PReP partitions. Specifically we're curious because we have a discussion topic which has been raised for the upcoming PTG. Thanks! -Julia

2 2

[Nova] Need to reschedule the Nova upstream meeting ⏰
by René Ribaud 06 Oct '25

06 Oct '25

Hi everyone, We need to move the current Nova upstream meeting, as most contributors, myself included, are busy in another meeting at that time. Finding a new slot is not straightforward, since some of our meetings are recurring and the daylight saving changes add additional complexity. Over the past few weeks, I tried to narrow down the possible options, and here’s a short poll with different time slots to choose from: https://framadate.org/ao12zK6wR3K3nfbF If none of these options work for you, or if you have other suggestions, please reply to this thread. Please note that we might need to adjust the schedule again later in the year, either due to daylight saving changes or if our other recurring meetings start to overlap again. Thanks for your understanding and input! Cheers, René

1 0

[publiccloud-sig] Public Cloud SIG meeting d.d. 8 October
by Kees Meijs | Nefos 06 Oct '25

06 Oct '25

Hello Stackers, The day after tomorrow (that's 8 October) the bi-weekly Public Cloud SIG meeting will be held again. The publicly available video meeting will be conducted from 07:00 hrs UTC (09:00 hrs CEST) and on here: https://meetpad.opendev.org/publiccloud-sig Additional information to be found on https://wiki.openstack.org/wiki/PublicCloudSIG Unfortunately I'm unable to join myself this episode, but obviously feel free to discuss relevant topics. See you next time, or next week in Paris. 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

[neutron] Bug deputy report for week 40 of 2025 (September 29)
by Lajos Katona 06 Oct '25

06 Oct '25

Hi Neutrinos! Last week (week 40, from September 29) I was the Neutron bug deputy, please check the report for that week. As usual the team will discuss these bugs quickly during the weekly team meeting: https://meetings.opendev.org/#Neutron_Team_Meeting High Bugs ---------------- * Unassigned: https://bugs.launchpad.net/neutron/+bug/2126032 ([CI] Random failure network create with Error while executing command: HttpException: 503, Unable to create the network. No tenant network is available for allocation.) Only on 2025.1 branch * eventlet: https://bugs.launchpad.net/neutron/+bug/2126790 (q-dhcp process is not gracefully shutting down ) * eventlet: https://bugs.launchpad.net/neutron/+bug/2126791 (q-agt process is not gracefully shutting down ) * https://bugs.launchpad.net/neutron/+bug/2126033 (2025.2 centos jobs fails as https://trunk.rdoproject.org/centos9-2025.2/delorean-deps.repo not exists ) Yatin follows it. * https://bugs.launchpad.net/neutron/+bug/2126061 ([ovs-agent] slow start with large number of ports ) patch: https://review.opendev.org/c/openstack/neutron/+/962627 * https://bugs.launchpad.net/neutron/+bug/2126576 ([S-RBAC] Policies for local_ip_association don't work as expected), patch: https://review.opendev.org/c/openstack/neutron/+/962751 * https://bugs.launchpad.net/neutron/+bug/2126759 ([S-RBAC] Policies for l3_conntrack_helpers don't work as expected ) patch: https://review.opendev.org/c/openstack/neutron/+/962919 Medium Bugs ------------------ * Unassigned; https://bugs.launchpad.net/neutron/+bug/2126637 ([OVN] Router "after_update" event contains wrong information with GW multihoming API ) * Unassigned: https://bugs.launchpad.net/neutron/+bug/2126685 (test_add_external_port_avoid_flapping functional test failure ) * https://bugs.launchpad.net/neutron/+bug/2126570 (DHCP agent - created port not stored in cache, may cause "stale" ) patch: https://review.opendev.org/c/openstack/neutron/+/962323 * https://bugs.launchpad.net/neutron/+bug/2126588 ([OVN] The Logical_Router pinning breaks the external ports HA_Chassis_Groups ) patch: https://review.opendev.org/c/openstack/neutron/+/962746 Best wishes, Lajos Katona (lajoskatona)

1 0

[OpenStack Ansible] [Deployment] Retrieve upper constraints issue
by holywine＠outlook.com 05 Oct '25

05 Oct '25

Hello, Following the instruction here (https://docs.openstack.org/project-deploy-guide/openstack-ansible/2025.1/) step by step to deploy openstack with openstack-ansible stable/2025.1 release on four computers (Infra1, Infra2, compute1, compute2) with a fifth computer as deployer (localhost)。 During the execution of command “openstack-ansible setup-infrastructure.yml” error pops up and installation broke. The log is as the following: ... TASK [repo_server : Ensure deploy host u-c directory exists] ******************************************************************************************* ok: [infra1-repo-container-769e886d -> localhost] TASK [repo_server : Retrieve upper constraints using https] ******************************************************************************************** FAILED - RETRYING: [infra1-repo-container-769e886d -> localhost]: Retrieve upper constraints using https (5 retries left). FAILED - RETRYING: [infra1-repo-container-769e886d -> localhost]: Retrieve upper constraints using https (4 retries left). FAILED - RETRYING: [infra1-repo-container-769e886d -> localhost]: Retrieve upper constraints using https (3 retries left). FAILED - RETRYING: [infra1-repo-container-769e886d -> localhost]: Retrieve upper constraints using https (2 retries left). FAILED - RETRYING: [infra1-repo-container-769e886d -> localhost]: Retrieve upper constraints using https (1 retries left). fatal: [infra1-repo-container-769e886d -> localhost]: FAILED! => attempts: 5 changed: false dest: /etc/openstack_deploy/upper-constraints/upper_constraints_bfd91c04caf498be2bfda0732a2a0f9fa9306e07.txt elapsed: 0 gid: 0 group: root mode: '0644' msg: 'Request failed: <urlopen error [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: unable to get local issuer certificate (_ssl.c:1000)>' owner: root size: 13007 state: file uid: 0 url: https://releases.openstack.org/constraints/upper/bfd91c04caf498be2bfda0732a… Can anybody please give a clue on what is going on and how to do troubleshooting? Thanks a lot in advance! Regards, Hewi

2 4

[OpenStack Ansible] [Deployment] Retrieve upper constraints issue
by holywine＠outlook.com 04 Oct '25

04 Oct '25

Hello, Following the instruction here (https://docs.openstack.org/project-deploy-guide/openstack-ansible/2025.1/) step by step to deploy openstack with openstack-ansible stable/2025.1 release on four computers (Infra1, Infra2, compute1, compute2) with a fifth computer as deployer (localhost)。 During the execution of command “openstack-ansible setup-infrastructure.yml” error pops up and installation broke. The log is as the following: ... TASK [repo_server : Ensure deploy host u-c directory exists] ******************************************************************************************* ok: [infra1-repo-container-769e886d -> localhost] TASK [repo_server : Retrieve upper constraints using https] ******************************************************************************************** FAILED - RETRYING: [infra1-repo-container-769e886d -> localhost]: Retrieve upper constraints using https (5 retries left). FAILED - RETRYING: [infra1-repo-container-769e886d -> localhost]: Retrieve upper constraints using https (4 retries left). FAILED - RETRYING: [infra1-repo-container-769e886d -> localhost]: Retrieve upper constraints using https (3 retries left). FAILED - RETRYING: [infra1-repo-container-769e886d -> localhost]: Retrieve upper constraints using https (2 retries left). FAILED - RETRYING: [infra1-repo-container-769e886d -> localhost]: Retrieve upper constraints using https (1 retries left). fatal: [infra1-repo-container-769e886d -> localhost]: FAILED! => attempts: 5 changed: false dest: /etc/openstack_deploy/upper-constraints/upper_constraints_bfd91c04caf498be2bfda0732a2a0f9fa9306e07.txt elapsed: 0 gid: 0 group: root mode: '0644' msg: 'Request failed: <urlopen error [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: unable to get local issuer certificate (_ssl.c:1000)>' owner: root size: 13007 state: file uid: 0 url: https://releases.openstack.org/constraints/upper/bfd91c04caf498be2bfda0732a… Can anybody please give a clue on what is going on and how to do troubleshooting? Thanks a lot in advance! Regards, Hewi

1 0

[kolla][kolla-ansible] Managing Object Storage Backend via Kolla-Ansible
by sarah.kh09＠gmail.com 04 Oct '25

04 Oct '25

Hello everyone, We are currently using Kolla-Ansible stable/2024.1 to manage our OpenStack deployment, including both core services and the Swift object storage backend. Our goal is to manage all OpenStack services, including object storage, through a unified lifecycle management tool. We understand that managing large volumes of data can affect the performance of other services. To address this, we've separated the data flow entry points that could become bottlenecks into dedicated host groups: a load balancer and a Swift proxy. Specifically, we've created two separate host groups: one for the secondary load balancer (which serves as the initial entry point) and another for the Swift proxy services. 🔹 Key Point 1: Decoupling Swift Traffic We’ve separated the Swift proxy nodes from the other OpenStack API services. This also means that the load balancer handling Swift traffic must be distinct from the main load balancer used for services like Nova, Glance, and Neutron. 🔹 Key Point 2: Keystone Endpoint Behavior Swift still registers with the existing Keystone service. Depending on the configuration: - If the second_loadbalancer is enabled, Keystone publishes the VIP (Virtual IP) of the secondary HAProxy as the Swift endpoint. - If it’s disabled, Keystone uses the direct API address of the Swift proxy node. 🔹 Key Point 3: Two Supported Configurations Kolla-Ansible supports two architecture models for Swift: Normal and Advanced. - Normal Configuration This is the default setup in stable/2024.1, where all OpenStack services, including Swift, share the same load balancer and traffic path. - Advanced Configuration This is recommended for large-scale deployments with heavy data volumes. In this setup, Swift traffic goes through a dedicated load balancer and proxy nodes, which reduces contention and improves performance. We’d love to share this approach with the community and welcome any feedback or suggestions. Our goal is to make managing both compute and storage services within a single deployment framework as simple as possible. Thanks in advance for your insights!

1 0