October 2025 - openstack-discuss - lists.openstack.org

[release] Release countdown for week R-24
by Thierry Carrez 10 Oct '25

10 Oct '25

Welcome back to the release countdown emails! These will be sent at major points in the 2026.1 "Gazpacho" development cycle, which should conclude with a final release on April 1st, 2026 (not a joke). Development Focus ----------------- At this stage in the release cycle, focus should be on planning the 2026.1 "Gazpacho" development cycle, assessing Gazpacho community goals and approving Gazpacho specs. General Information ------------------- The 2026.1 "Gazpacho" development cycle will be a classic 26-week-long cycle. In case you haven't seen it yet, please take a look over the schedule for this release: https://releases.openstack.org/gazpacho/schedule.html By default, the team PTL is responsible for handling the release cycle and approving release requests. This task can (and probably should) be delegated to release liaisons. Now is a good time to review release liaison information for your team and make sure it is up to date: https://opendev.org/openstack/releases/src/branch/master/data/release_liais… By default, all your team deliverables from the 2025.2 "Flamingo" release are continued in 2026.1 "Gazpacho" with a similar release model. Upcoming Deadlines & Dates -------------------------- OpenInfra Summit Europe: October 17th-19th, 2025 OpenStack PTG (virtual): October 27th-31st, 2025 Gazpacho-1 milestone: November 13th, 2025 -- Thierry Carrez (ttx)

1 0

[neutron] Drivers meeting canceled Friday, October 10th
by Brian Haley 09 Oct '25

09 Oct '25

Hello Neutrinos: I am going to cancel tomorrow's Drivers meeting as there are no topics and I will be out. At this point we should probably just add things to the PTG etherpad and discuss there [0]. Just a reminder there are still open specs that need updates and/or review, list is at [1]. Have a nice weekend! -Brian [0] https://etherpad.opendev.org/p/oct2025-ptg-neutron [1] https://review.opendev.org/q/status:open+project:openstack/neutron-specs

1 0

[PTLs] [OpenStack TC] Anonymized User Survey Feedback
by Jimmy McArthur 09 Oct '25

09 Oct '25

As you know each year we conduct an OpenStack User Survey. A big chunk of that survey data is dedicated to OpenStack projects, WGs, etc… I’d like to invite you all to review the anonymized feedback from 2025[1]. Please review not only for feedback, but to determine if you want to update your TC, PTL or WG questions. Additionally, if the TC can ensure that questions are up to date wrt to project or working group status. For example, we know the InteropWG has been disbanded as of this year, so we should probably remove those questions for 2026. We would like to have ALL reviews/requests in no later than December 1, 2025. If we do not hear from your project, we will assume you want no changes. If you have any questions, please let myself or Allison Price know. Cheers, Jimmy [1] https://docs.google.com/spreadsheets/d/1bte_k0R3_rVzFF9ND5zTZV0j9liXI1PxPNo…

2 2

[neutron] oslo.messaging and port notifications broadcast
by Thomas Goirand 08 Oct '25

08 Oct '25

Hi, Is it possible, with oslo.messaging, to have 3 daemons to get the Neutron port.{create,update,delete}.end notification events? I tried hard, but no mater how I do it, only one of my 3 daemons get the message. I'm about to add forwarding feature to the other 2 when one receives an event. Is there a better way? Cheers, Thomas Goirand (zigo)

5 12

[PTL][release][stable] 2024.1 Caracal transition to Unmaintained
by Elõd Illés 08 Oct '25

08 Oct '25

Hi teams, As 2025.2 Flamingo was released last week and we are in a less busy period, now is the good time to call your attention to the following: At the end of October 2024.1 Caracal is planned to transition to Unmaintained phase [1] (planned date: 2025-10-24). I have generated the list of the current *open* and *unreleased* changes in stable/2024.1 for every repositories [2] (where there are such patches). These lists could help the teams who are planning to do a *final* release on Caracal before moving stable/2024.1 branches to unmaintained/2024.1. Feel free to edit and extend these lists to track your team's progress! Note that the last hash on stable/2024.1 branch will be tagged ('2024.1-eom' tag) and transition patches will be generated soon. After the tagging and cutting unmaintained/2024.1 branch, the new unmaintained branch will be open to for bug fixes, but there won't be official releases for 2024.1 Caracal anymore. (You can get some information about the Unmaintained state on stable policy page [3]). *NOTE*: teams, please focus on wrapping up your libraries first if there is any concern about the changes, in order to avoid broken (final!!) releases! [1] https://releases.openstack.org/ [2] https://etherpad.opendev.org/p/2024.1-caracal-final-release-before-eom [3] https://docs.openstack.org/project-team-guide/stable-branches.html#unmainta… Thanks, Előd Illés irc: elodilles @ #openstack-release

1 0

[kolla] Next two weekly meetings - 8th Oct and 15th Oct
by Michał Nasiadka 07 Oct '25

07 Oct '25

Hello, The next two weekly meetings for Kolla are cancelled: 8th Oct (today) - due to unavailability of key participants 15th Oct (next week) - due to OpenInfra Summit

1 0

[ptl][venus][tc] Need a PTL volunteer for OpenStack Venus project team
by Goutham Pacha Ravi 07 Oct '25

07 Oct '25

Hello Stackers, We're missing a Project Team Lead (PTL) for the OpenStack Venus project team for the "2026.1" (Gazpacho) release cycle. If you're interested, please let us know by proposing a PTL appointment (e.g. [1]). Thanks, Goutham Pacha Ravi (gouthamr) [1] https://review.opendev.org/c/openstack/governance/+/899781

1 2

[ptl][vitrage][tc] Need a PTL volunteer for OpenStack Vitrage project team
by Goutham Pacha Ravi 07 Oct '25

07 Oct '25

Hello Stackers, We're missing a Project Team Lead (PTL) for the OpenStack Vitrage project team for the "2026.1" (Gazpacho) release cycle. If you're interested, please let us know by proposing a PTL appointment (e.g. [1]). Thanks, Goutham Pacha Ravi (gouthamr) [1] https://review.opendev.org/c/openstack/governance/+/882139

1 2

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

07 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’ve attached an architectural diagram to better illustrate the setup. 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!

3 3

[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