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

[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

[Kolla][Kolla-Ansible] Making the use of mirrors easier on container build
by Michael Still 04 Oct '25

04 Oct '25

Oh hello, For the last couple of years I've been working on trying to improve the VDI experience in OpenStack by enriching our SPICE capabilities. A series of patches has now landed in Nova that enable SPICE native console sessions from outside the cloud, I have a working (but probably not completely finished) SPICE native proxy, and the next step is adding deployment support to Kolla-Ansible so that I can start demoing an end to end implementation. I have a draft of those changes, but don't feel quite ready to push them to Gerrit just yet. As part of that I've been building my own Kolla images in my homelab CI environment for a couple of years now. I don't know about others, but for me by far the most common reason for these builds to fail is because of intermittent connectivity to upstream package repositories -- either flaky networking, random noise, or rate limiting. Increasingly I find myself carrying private patches to use local mirrors instead of the upstream sources. It occurs to me I might not be the only one with this sort of use case. I therefore wonder how the Kolla team would feel about abstracting the upstream sources of various build dependencies so that they were defined centrally? That would make it much easier both to override sources with local mirrors, as well as define exactly what upstream sources are required to conduct a build. If that's a reasonable thing to do, where would people see that list sitting? My initial thought is in the defaults for the kolla-build ansible role, but I am definitely not a Kolla expert so I am open to guidance here. Cheers, Michael -- Person on the internet. https://madebymikal.com. He / his / him.

2 2

[blazar] Meeting cancelled 16th October 2025
by Matt Crees 02 Oct '25

02 Oct '25

Hi all, Due to lack of availability of the core team, the fortnightly Blazar meeting will be cancelled on the 16th October. This means the next time that we'll meet will be at the PTG. I look forward to seeing you all there. Kind regards, Matt Crees, on behalf of the Blazar project.

1 0