September 2026 - openstack-discuss

[requirements][all] Can we branch openstack/requirements earlier?
by Stephen Finucane 16 Sep '26

16 Sep '26

o/ In Hibiscus, the OSC and Oslo feature freezes occurred at R-7 (i.e. 7 weeks before the release), while the deadline for other non-client libraries (which I believe includes things like ksa and SDK) occurred at R-6 and client library deadline occurred a week later at R-5 (Milestone 3). This has long presented a challenge: we lose 10-14 weeks a year during which we cannot release anything merged to 'master' for these deliverables. I'd like to propose a change for the forthcoming Indri cycle. Rather than having a 7 week freeze period, I'd like to see us branch openstack/requirements at Milestone 3, when we create branches for all non-service and non-trailing release deliverables. I would also like us to start pushing the TOX_CONSTRAINTS_FILE patches (e.g. [1]) to `master` branches for services rather than waiting until the branch happens. We can then revert this value to `master` as part of our `Update master` patch (e.g. [2]). This would ensure services continue testing against the u-c of the forthcoming release until branching occurs. Making these changes would in turn allow us to create the new deliverable files for the forthcoming cycle and allow libraries and clients to continue moving forward, rather than downing tools. Is there any reason we can't do something like this? I have proposed some tooling changes that allows us to generate the new deliverable files for specific deliverable types [3]. I'd be happy to work with the release team to adjust the other tooling in order to allow this to happen. Cheers, Stephen [1] https://review.opendev.org/c/openstack/neutron/+/1005103 [2] https://review.opendev.org/c/openstack/neutron/+/1005104 [3] https://review.opendev.org/c/openstack/releases/+/1005720 PS: For people asking why we don't just move all these deliverables to the 'independent' release model, this was actually tried for the Oslo project in the past and it didn't work out. By following the 'cycle-with-intermediary' release model, we ensure we get at least one release a cycle. When the deliverables switched to 'independent', this forcing function was lost. Additionally, 'independent' turns out to be a bit of a misnomer: we can't exactly drop support for a version of Python that is specified in the Supported Runtimes for the current release, and unless you want to go and manually specify your own Zuul job templates, you're going to be testing against the same release-specific runtimes. None of this changes the fact that a library like debtcollector is no different to any non-OpenStack package like requests when it comes to "dependence" (or lack thereof) on a given OpenStack version.

1 0

October 2026 PTG Team List Annoucement
by Kendall Nelson 16 Sep '26

16 Sep '26

Hello Everyone! The October 2026 Project Teams List is official! If your team was planning to meet and isn’t in the list below, please contact ptg(a)openinfra.org IMMEDIATELY. *Projects + Teams* *OpenInfra Project Teams* - Kata Containers - StarlingX - OpenStack - Services - Blazar - Cloudkitty - Designate - Glance - Horizon - Keystone - Kolla - Manila - Magnum - Masakari - Neutron - Nova - Octavia - OpenStackSDK - Sunbeam - Other OpenStack Teams - Eventlet Removal - Technical Committee *Other OpenInfra Community Teams* - OpenInfra Marketing - Digital Sovereignty WG - Fun & Games! Soon I will be contacting moderators to sign up for time via the PTGBot[1] once it is configured to begin scheduling meeting times. In the meantime, please register if you haven't done so already and encourage your teams to do so as well[2]. As usual, feel free to let us know if you have any questions! Thanks! -Kendall (diablo_rojo) [1] PTGBot Docs: https://opendev.org/openstack/ptgbot#open-infrastructure-ptg-bot [2] PTG Registration: https://ptg.openinfra.org/

3 2

[tc][barbican][horizon] Reviving barbican-ui: proposing a dedicated core reviewer group
by Mauricio Harley 16 Sep '26

16 Sep '26

Hi all, This follows up on a topic that came up in the OpenStack TC meetings back in July: a group of contributors (Ivan Anfimov, Kiran Pawar, and others) has been actively reviving barbican-ui, replacing the old, unmaintained AngularJS frontend with a Django/Horizon-native implementation. See the open changes here: https://review.opendev.org/q/project:openstack/barbican-ui+status:open. The barbican-core team does not have dedicated frontend/Horizon expertise, which has made it hard for us to confidently review and merge these changes. As Barbican PTL, I'm not opposed to this work at all, but I think the right way forward is to have a dedicated reviewer group for barbican-ui (e.g. a barbican-ui-core Gerrit group) made up of people with frontend/Horizon experience, rather than gatekeeping this through barbican-core. I'd like to propose: 1. Creating a barbican-ui-core Gerrit group scoped to the openstack/barbican-ui repository. 2. Populating it with contributors actively working on the revival, plus anyone from the Horizon team willing to help review. 3. Building reviewer confidence with solid test coverage - ideally including integration tests (Selenium/Playwright), similar to what manila-ui and watcher have done - rather than treating this as a hard blocker, as suggested in the TC discussion. If you're interested in joining this group, or have opinions on scope or membership, please reply here. I've also put this on the agenda for our next biweekly Barbican meeting: Monday, September 28th, 2026, 15:00 UTC, on #openstack-barbican (IRC/Matrix). Agenda: https://etherpad.opendev.org/p/barbican-weekly-meeting Feel free to join live, or just add your thoughts to the etherpad/this thread if the time doesn't work for you. Thanks, mharley Barbican PTL

2 1

[all][ptl][dpl] Please submit release cycle highlights and call out security work
by Goutham Pacha Ravi 15 Sep '26

15 Sep '26

Hello Stackers, Now that we are past the RC1 deadline for the 2026.2 "Hibiscus" release, it’s time to showcase all the work your project teams have accomplished over the 2026.2 cycle. The OpenInfra Foundation (and the broader community) relies on these highlights to communicate our progress to operators, end users, and contributors. We've had a handful of Project highlights so far [1], so please take a few minutes to submit your team's highlights before the release window closes. Cycle highlights as usual are meant to include major additions, user-facing improvements, and significant architecture updates done with a project deliverable. This cycle, we would like to include "Security & Maintenance Toil" prominently. If your team spent considerable time on security work—such as security bugfixes, security audits and threat modeling, security bug triage, non-advisoriable security fixes, or code hardening—please highlight it! We want to recognize the heavy maintenance load and signal our commitment to keeping OpenStack securable, even when that work takes priority over new features. To submit your highlights, propose a patch to the release highlights in the openstack/releases repository. Use the hashtag "2026.2-cycle-highlights" on your Gerrit review. Please do this by the end of this week (Sep 18) so we can aggregate the data in time for the official release announcements. Thanks for all your hard work this cycle! On behalf of the OpenStack TC, Goutham Pacha Ravi (gouthamr) [1] https://review.opendev.org/q/hashtag:%222026.2-cycle-highlights%22+(status:…

1 0

[openstack][kolla ansible]about upgrade large system
by Nguyễn Hữu Khôi 15 Sep '26

15 Sep '26

Hi, I am going to upgrade my OpenStack system. I have upgraded it successfully once before, but this time I would like to know if we can follow this path: upgrade the control plane on the first day, then upgrade the first batch of compute nodes on the second day, and the second batch on the third day. I'm asking because if we have hundreds of servers, we cannot upgrade them all in a single day. I currently have OpenStack 2025.1 and am planning to upgrade to 2026.1. I would be glad to hear any ideas from you. Many thanks. Nguyen Huu Khoi

2 3

[charms] Proposing Seyeong Kim for charms-stable-maint
by Edward Hope-Morley 15 Sep '26

15 Sep '26

Hi all, Seyeong has years of experience with the OpenStack charms and for the last year has been actively working as a reviewer to compliment his contributions. I'd like to propose Seyeong as a member of the charms-stable-maint team. Cheers, Ed

3 2

[tc][all] OpenStack Technical Committee Weekly Summary and Meeting Agenda (2026.2/R-2)
by Goutham Pacha Ravi 14 Sep '26

14 Sep '26

Hello Stackers, We're two weeks away from the date of the coordinated release of OpenStack 2026.2 "Hibiscus" [1]. Most OpenStack deliverables following the "cycle-with-rc" model have tagged their first release candidates for the Hibiscus cycle. PTLs and liaisons have been putting together the release cycle highlights [2]. If your project team hasn't done this yet, please do so at the earliest by submitting a change to the releases repository [3]. Voting for the ongoing TC election closes this Wednesday, September 16 at 23:45 UTC. Five candidates are running for open TC seats this term: Artem Goncharov (gtema), Bartosz Bezak (bbezak), Christian Berendt (berendt), Doug Goldstein (cardoe), and Dr. Jens Harbott (frickler). Please make your vote count, and tell others to do the same [4]. === Weekly Meeting === The last weekly meeting of the OpenStack Technical Committee was held on September 08, 2026 [5]. During the meeting, we cleaned up the core reviewer teams in "service-types-authority" and the "os-service-types" library. We then discussed three deliverables under the openstack/tacker team: tosca-parser, python-tackerclient, and tacker-horizon. These haven't seen meaningful movement during this cycle and the release team flagged that auto-proposed bot patches weren't merged either. We flagged the concern on this mailing list [6] as well. cardoe raised the issue that it has gotten hard to land changes in Keystone. Part of this is due to the fact that the core team's bandwidth has been consumed by triaging and patching security vulnerabilities of late. We acknowledged that this problem isn't unique to Keystone. However, gtema, the Keystone PTL, mentioned that a side effect of the lack of bandwidth is that Keystone's architecture can't take drive-by contributions anymore, and some parts need a full redesign. The TC sees a need to unblock people to maintain what exists and build something new (the "redesign") in parallel. I don't expect this to be resolved quickly, so we postponed some of the discussion to the next meeting. There is an open governance proposal seeking to add Rust as an official language. This proposal is a precursor to the Keystone team's desire to re-write Keystone using Rust. Please do weigh in. The next meeting of the OpenStack TC is Tuesday September 15, 2026, at 1700 UTC. This meeting will be hosted on the #openstack-tc channel on OFTC. Please see the agenda on the meeting's wiki page [7]. I hope to see you there. === Governance Proposals === ==== Merged ==== - Add frickler as QA release liaison | https://review.opendev.org/c/openstack/governance/+/1005091 - Update location of liaison reference | https://review.opendev.org/c/openstack/governance/+/1005109 ==== Open for Review ==== - doc: Add PTL doc | https://review.opendev.org/c/openstack/governance/+/1005080 - Add PQC Readiness as a proposed community goal | https://review.opendev.org/c/openstack/governance/+/1001777 - Retire barbican's ansible roles | https://review.opendev.org/c/openstack/governance/+/995081 - Propose SECURITY.rst goal | https://review.opendev.org/c/openstack/governance/+/1002692 - Add liaison-update hashtag with PTL/liaison CR+1 check | https://review.opendev.org/c/openstack/governance/+/1001440 - Add Rust use-case analysis for Keystone | https://review.opendev.org/c/openstack/governance/+/998652 - Start testing pre-release versions for clients and libraries | https://review.opendev.org/c/openstack/governance/+/992767 - Distinguish between tested runtimes for clients and libraries | https://review.opendev.org/c/openstack/governance/+/992765 === Upcoming Events === - 2026-09-17: PyCon Cameroon + Ubucon Cameroon: https://cm.pycon.org - 2026-09-25: 2026.2 "Hibiscus" final release candidates due: https://releases.openstack.org/hibiscus/schedule.html - 2026-09-30: 2026.2 "Hibiscus" coordinated release - 2026-10-07: Open Source Summit Europe | Embedded Linux Conference Europe: https://events.linuxfoundation.org/open-source-summit-europe/ - 2026-10-12: 2027.1 "Indri" Project Team Gathering (virtual, through Oct 16): https://openinfra.org/ptg/ - 2026-10-22: OpenInfra track at Sovereign Cloud Days Germany: https://www.sovereign-cloud-days.eu/en Thank you very much for reading! On behalf of the OpenStack TC, Goutham Pacha Ravi (gouthamr) OpenStack TC Chair [1] 2026.2 "Hibiscus" Release Schedule: https://releases.openstack.org/hibiscus/schedule.html [2] 2026.2 "Hibiscus" Release Cycle Highlights: https://releases.openstack.org/hibiscus/highlights.html [3] Adding cycle highlights: https://review.opendev.org/q/hashtag:%222026.2-cycle-highlights%22+(status:… [4] TC Election reminder: https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack… [5] TC Meeting IRC Log, September 08 2026: https://meetings.opendev.org/meetings/tc/2026/tc.2026-09-08-17.00.html [6] Tacker release concerns: https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack… [7] TC Meeting Agenda, September 15 2026: https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Next_Meeting

1 0

[tc][tacker] Release liaison gap + inactive deliverables under the Tacker team
by Goutham Pacha Ravi 14 Sep '26

14 Sep '26

This came up at this week's TC meeting: https://meetings.opendev.org/meetings/tc/2026/tc.2026-09-08-17.00.log.html#… The release team's cycle-end review found three Tacker deliverables with no merged changes this cycle: tosca-parser, python-tackerclient, and tacker-horizon (cycle-with-rc). Two final releases went out without PTL/liaison acknowledgment: - https://review.opendev.org/c/openstack/releases/+/1003754 (tosca-parser force release) - https://review.opendev.org/c/openstack/releases/+/1002780 (python-tackerclient final release for 2026.2 Hibiscus) python-tackerclient also has auto-proposed bot patches sitting unmerged: https://review.opendev.org/q/is:open+project:openstack/python-tackerclient+… We suspect this is a bandwidth issue rather than a signal that these are unmaintained. We see that the tacker repository sees regular activity. If the PTL is stretched thin, this is exactly what a release liaison could own: acknowledging release team requests and flagging when a deliverable should move to independent release or be retired. Tacker team / yasufum — could you (a) designate a release liaison if you haven't already, and (b) let us know whether tosca-parser/python-tackerclient/tacker-horizon should go independent or be retired? On behalf of the OpenStack TC, Goutham Pacha Ravi (gouthamr)

2 2

[all][elections][tc] TC Election Voting Last Days
by Ian Y. Choi 14 Sep '26

14 Sep '26

We are coming down to the last hours for voting in the TC election. Voting ends Sep 16, 2026 23:45 UTC. Search your gerrit preferred email address[0] for the following subject: Poll: OpenStack 2027.1 Cycle Technical Committee Election Poll That is your ballot and links you to the voting application. Please vote. If you have voted, please encourage your colleagues to vote. Candidate statements are linked to the names of all confirmed candidates: https://governance.openstack.org/election/#tc-candidates What to do if you don't see the email and have a commit in at least one of the official project teams' deliverable repositories[1]: * check the trash of your gerrit Preferred Email address[0], in case it went into trash or spam * wait a bit and check again, in case your email server is a bit slow * find the sha of at least one commit from an official deliverable repo[1] and email the election officials[2]. If we can confirm that you are entitled to vote, we will add you to the voters list and you will be emailed a ballot. Please vote! Thank you, [0] Sign into review.openstack.org: Go to Settings > Contact Information. Look at the email listed as your Preferred Email. That is where the ballot has been sent. [1] https://opendev.org/openstack/governance/src/tag/0.23.0/reference/projects.… [2] https://governance.openstack.org/election/#election-officials

1 0

[neutron] Bug deputy report for week of September 7th
by Brian Haley 14 Sep '26

14 Sep '26

Hi, I was the Neutron bug deputy last week. Below is a short summary about the reported bugs. -Brian High bugs --------- * https://bugs.launchpad.net/neutron/+bug/2166694 - L3 HA router state file written as root causes Permission denied for neutron-l3-agent - https://review.opendev.org/c/openstack/neutron/+/1004419 * https://bugs.launchpad.net/neutron/+bug/2166707 - Intermittent IPv6 failure in neutron-ovn-bgp-tempest-multinode: VM second NIC stuck with DADFAILED link-local and no global address - Needs owner * https://bugs.launchpad.net/neutron/+bug/2167105 - [OVN] Trunk driver incorrectly manages trunks with an "external" type parent port (baremetal/SR-IOV) - Rodolfo assigned to himself * https://bugs.launchpad.net/neutron/+bug/2167141 - [OVN] When using routed networks with multiple segments per host, some patch ports may be deleted when a host is rebooted - Miguel assigned to himself Medium ------ * https://bugs.launchpad.net/neutron/+bug/2166686 - neutron leaking ml2_distributed_port_bindings rows - https://review.opendev.org/c/openstack/neutron/+/1004415 - https://review.opendev.org/c/openstack/neutron/+/1004416 * https://bugs.launchpad.net/neutron/+bug/2166698 - `test_multiple_routers_then_delete_one` randomly failing - https://review.opendev.org/c/openstack/neutron/+/1004718 Low --- * https://bugs.launchpad.net/neutron/+bug/2166744 - [vpnaas] Move oslo.config options into neutron_vpnaas/conf/ - https://review.opendev.org/c/openstack/neutron-vpnaas/+/1004571 Wishlist -------- * https://bugs.launchpad.net/neutron/+bug/2167078 - [RFE] Allow reschedule of the routes to the nodes in different availability zone

1 0