- openstack-discuss - lists.openstack.org

[freezer] Activity on this project?
by Jimmy McArthur 08 Sep '25

08 Sep '25

Are there orgs or individuals that are working on Freezer and/or have interest in working on Freezer? Cheers, Jimmy

4 3

[tc][all] OpenStack Technical Committee Weekly Summary and Meeting Agenda (2025.2/R-3)
by Goutham Pacha Ravi 08 Sep '25

08 Sep '25

Hello Stackers, We're three weeks away from the coordinated 2025.2 "Flamingo" release [1]. This week, project teams are testing code changes and merging bug fixes to deliver release candidates for deliverables that follow a "cycle-with-rc" release model [2]. Polls for electing a PTL for the OpenStack Dashboard ("Horizon") project team, as well as for four members to the OpenStack Technical Committee, are still open. They will close on September 17th, 2025, at 23:45 UTC [3]. In the past week, election officials reached out to a section of the electorate that hadn't opted in to emails on the election system: CIVS. Please do contact the election officials [3] if you are having trouble finding your ballot. Besides this, governance updates included marking the conclusion of the goal to migrate WSGI scripts across all OpenStack services [4] and adding new metadata to project tracking to highlight inactive OpenStack projects. This will help us make release and documentation updates to clearly flag deliverables that need help from new (or existing) contributors, as well as serve as a health indicator to operators and users. === Weekly Meeting === The last weekly meeting of the OpenStack Technical Committee occurred on September 2nd, 2025, simultaneously over Meetpad [5] and IRC [6]. The "Migrate from WSGI scripts to module paths" goal was completed [4]. A significant portion of the meeting was spent discussing the proposed retirement of the Monasca project team. The TC considered whether to recommend forking the project into a new namespace on opendev.org under the aegis of the volunteer who wants to maintain it. We also discussed the need to update documentation and README files to reflect the project's maintenance status and to implement automated updates for this process. We discussed the ongoing elections, where an early retrospective item was to urge existing members to renew their OpenInfra Foundation memberships and to opt in to CIVS emails. The team reviewed "leaderless teams" and the status of projects like Vitrage, Venus and OpenStack Charms, noting that a PTL candidate is still needed. We took an action item to tag retired packages on PyPi as part of the repository retirement process. Finally, the group briefly touched on gate health issues related to Debian Trixie nodes and a new discussion point about default MySQL/MariaDB charset/collations that will be addressed in the next meeting. The next meeting of the OpenStack TC is on September 9th, 2025, at 1700 UTC. This meeting will be hosted in the #openstack-tc channel on OFTC. Please find the meeting's agenda on its wiki page [7]. I hope you'll be able to join us there. === Governance Proposals === ==== Merged ==== - Show inactive project status in project.yaml | https://review.opendev.org/c/openstack/governance/+/958229 - Mark "Migrate from WSGI scripts" goal as completed | https://review.opendev.org/c/openstack/governance/+/958817 ==== Open For Review ==== - Retire metalsmith project from bare metal program | https://review.opendev.org/c/openstack/governance/+/958297 - 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 - Extend Monasca's inactive state | https://review.opendev.org/c/openstack/governance/+/959392 === Upcoming Events === - 2025-09-09: OIF Board Monthly meeting: https://board.openinfra.org/ - 2025-09-17: OpenStack TC and Horizon project elections conclude: https://governance.openstack.org/election/ - 2025-10-01: OpenStack 2026.1 "Flamingo" release day - 2025-10-03: OpenStack's Birthday Meetup, Austin: https://www.meetup.com/openinfra-austin/events/310508680 - 2025-10-17: OpenInfra Summit, Paris-Saclay: https://summit2025.openinfra.org/ - 2025-10-27: OpenInfra PTG: https://openinfra.org/ptg/ === How to Contact the TC === You can reach the TC in several ways: - Email: send an email with the tag [tc] on this mailing list. - Ping us using the 'tc-members' keyword on the #openstack-tc IRC channel on OFTC. - Join us at our weekly meeting: The Technical Committee meets every week on Tuesdays at 1700 UTC [7]. Thank you very much for reading! On behalf of the OpenStack TC, Goutham Pacha Ravi (gouthamr) OpenStack TC Chair [1] 2025.2 "Flamingo" Release Schedule: https://releases.openstack.org/flamingo/schedule.html [2] "cycle-with-rc" release model: https://releases.openstack.org/reference/release_models.html#cycle-with-rc [3] OpenStack Elections: https://governance.openstack.org/election/ [4] Community Goal to update WSGI configuration: https://governance.openstack.org/tc/goals/proposed/migrate-from-wsgi-script… [5] TC Meeting Video Recording, Sep 2nd, 2025: https://youtu.be/K_tdk4mkxT0 [6] TC Meeting IRC Log, Sep 2nd, 2025: https://meetings.opendev.org/meetings/tc/2025/tc.2025-09-02-17.01.html [7] TC Meeting Agenda, Sep 9th, 2025: https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Next_Meeting

1 0

[watcher] Core team updates - removals, reminders, and new addition
by Sean Mooney 08 Sep '25

08 Sep '25

Hi everyone, I'm writing to propose some updates to the Watcher core team membership to ensure we maintain an active and engaged core review team. ## Proposed Removals (Immediate) The following core reviewers have been inactive for an extended period and I propose to remove them from all Watcher core groups: * Alexander Chadin (joker946(a)gmail.com) - last contribution: 26 Feb 2019 https://www.stackalytics.io/?module=watcher-group&release=all&user_id=joker… <https://www.stackalytics.io/?module=watcher-group&release=all&user_id=joker…> * Vincent Françoise (Vincent.FRANCOISE(a)b-com.com) - last contribution: 15 Mar 2019 https://www.stackalytics.io/?module=watcher-group&release=all&user_id=vince… <https://www.stackalytics.io/?module=watcher-group&release=all&user_id=vince…> * YumengBao (yumeng_bao(a)yahoo.com) - last contribution: 09 Apr 2020 https://www.stackalytics.io/?module=watcher-group&release=all&user_id=yumen… <https://www.stackalytics.io/?module=watcher-group&release=all&user_id=yumen…> * aditi sharma (adi.sky17(a)gmail.com) - last contribution: 22 Nov 2018 https://www.stackalytics.io/?module=watcher-group&release=all&user_id=adi-s… <https://www.stackalytics.io/?module=watcher-group&release=all&user_id=adi-s…> * licanwei (li.canwei2(a)zte.com.cn) - last contribution: 21 Jan 2021 https://www.stackalytics.io/?release=all&user_id=li-canwei2&module=watcher-… <https://www.stackalytics.io/?release=all&user_id=li-canwei2&module=watcher-…> * suzhengwei (sugar-2008(a)163.com) - last contribution: 13 Sep 2022 https://www.stackalytics.io/?module=watcher-group&release=all&user_id=sue.s… <https://www.stackalytics.io/?module=watcher-group&release=all&user_id=sue.s…> We want to thank all these contributors for their valuable work and contributions to the Watcher project over the years for there time and effort. ## Core Activity Notice (Removal planned for 2026.2) The following core reviewers are currently showing low activity levels. We're providing advance notice that they will be removed from the core group at the start of the 2026.2 cycle unless they become active again during the 2026.1 cycle: * chenker (chen.ke14(a)zte.com.cn) * Dan Smith (dms(a)danplanet.com) * Marios Andreou (marios.andreou(a)gmail.com) * Slawek Kaplonski (skaplons(a)redhat.com) We recognize that over time priorities change, if you wish to maintain their core status and can re-engage or wish to be be removed before we review the core composition again at the start of 2026.2 just let us know. ## New Core Proposal I would also like to propose adding jgilaber (jgilaber(a)redhat.com) as a new member of the watcher-core group, based on their recent contributions and engagement with the project. ## Timeline These changes will take effect if there are no objections by our next Watcher IRC meeting on Thursday, September 11th, 2025. Please share any feedback or concerns about these proposed changes. Regards sean

4 3

October 2025 PTG Team Signup Final Call
by Kendall Nelson 08 Sep '25

08 Sep '25

Hello Everyone, Make sure to sign your team up for the next virtual Project Teams Gathering (PTG), which will be held from Monday, October 27th to Friday, October 31st 2025! If you haven't already done so and your team is interested in participating, you need to complete the survey[1] by September 14th, 2025 at 7:00 UTC. Please also make sure to register[2] for the event - it’s free :) Thanks! -Kendall (diablo_rojo) [1] Team Survey: https://openinfrafoundation.formstack.com/forms/oct2025_ptg_survey [2] PTG Registration: http://ptg.openinfra.dev/

1 0

[neutron] Bug deputy - week of September 1st
by Sławek Kapłoński 08 Sep '25

08 Sep '25

Hi, It was pretty quiet week. Here are details about what happened: ### High - https://bugs.launchpad.net/neutron/+bug/2122065 - ovs agent missing openflow rules due to python error - assigned to Brian, fix proposed https://bugs.launchpad.net/neutron/+bug/2122065 ### Medium - https://bugs.launchpad.net/neutron/+bug/2122110 - [FT] Random errors in OVN ``TestMetadataAgent`` tests - assigned to Rodolfo, fix already proposed, - https://bugs.launchpad.net/neutron/+bug/2122079 - DHCP agent incorrectly releasing leases due to missing client_id - unassigned, Brian already commented there but solution for this may not be that easy to figure out according to the bug report and Brian's comment, ### Low - https://bugs.launchpad.net/neutron/+bug/2121935 - [FT] Random ``DBReferenceError`` errors in the functional tests Edit - assigned to Rodolfo, fix already proposed - https://bugs.launchpad.net/neutron/+bug/2122107 - [FT] Test ``test_initialize_network_segment_range_support_parallel_execution`` failing in the eventlet-removal patch - assigned to Rodolfo, ### To triage - https://bugs.launchpad.net/neutron/+bug/2121961 - Duplicate packet logs with openvswitch driver Edit - I asked Elvira to take a look at it. -- Slawek Kaplonski Principal Software Engineer Red Hat

1 0

Making WIP patch Active (without owner)
by Nimesh Desai 08 Sep '25

08 Sep '25

After the resolving the merge conflict, the following IBM Cinder driver patch is now in ‘Work in Progress’ state. We want to now make it Active, but the owner of the patch is no longer working with the organisation. Thus, the Gerrit UI is not showing option to publish. How to make this patch Active again? The patch was reviewed and had multiple +1 votes earlier. Patch: https://review.opendev.org/c/openstack/cinder/+/879839

6 8

[qa] PTL/Tempest core on PTO
by Ghanshyam Maan 05 Sep '25

05 Sep '25

Hi All, I would like to let you know that I will be on PTO and will return after the 2025.2 release. I will try to check IRC occasionally for any urgent changes that require merging, particularly in Tempest (as there is no other active core). -gmaan

1 0

[release] Release countdown for week R-3
by Thierry Carrez 05 Sep '25

05 Sep '25

Development Focus ----------------- The Release Candidate (RC) deadline is next Friday, September 12th, 2025. Work should be focused on fixing any release-critical bugs. General Information ------------------- All deliverables released under a cycle-with-rc model should have a first release candidate by the end of the week, from which a stable/2025.2 branch will be cut. This branch will track the 2025.2 "Flamingo" release. Once stable/2025.2 has been created, the master branch will be ready to switch to 2026.1 "Gazpacho" development. While the master branch will no longer be feature-frozen, please prioritize any work necessary for completing 2025.2 "Flamingo" plans. Release-critical bugfixes will need to be merged in the master branch first, then backported to the stable/2025.2 branch before a new release candidate can be proposed. Actions ------- Early in the week, the release team will be proposing RC1 patches for all cycle-with-rc projects, using the latest commit from the master branch. If your team is ready to go for cutting RC1, please let us know by leaving a +1 on these patches. If there are still a few more patches needed before RC1, you can -1 the patch and update it later in the week with the new commit hash you would like to use. Remember, stable/2025.2 branches will be created with this, so you will want to make sure you have what you need included to avoid needing to backport changes from the master branch (which will technically then be 2026.1 "Gazpacho") to this stable branch for any additional RCs before the final release. The release team will also be proposing releases for any deliverable following a cycle-with-intermediary model that has not produced any 2025.2 "Flamingo" release so far. Finally, now is a good time to finalize release highlights. Release highlights help shape the messaging around the release and make sure that your work is properly represented. Upcoming Deadlines & Dates -------------------------- RC1 deadline: September 12th, 2025 (R-3 week) Final RC deadline: September 26th, 2025 (R-1 week) Final 2025.2 "Flamingo" release: October 1st, 2025 OpenInfra Summit Europe: October 17th-19th, 2025 -- Thierry Carrez (ttx)

1 0

[qa][ptg] Call for 2026.1 vPTG QA topic
by Ghanshyam Maan 04 Sep '25

04 Sep '25

Hi All, I have created the etherpad to collect the QA topics for the coming vPTG (2026.1 cycle). Based on the topics, we will decide if we need any slot in PTG. Feel free to add your topics before Sept 12th. - https://etherpad.opendev.org/p/qa-2026.1-ptg -gmann

1 0

[oslo] status of eventlet removal for oslo.service?
by Chris Friesen 04 Sep '25

04 Sep '25

Hi everyone, Looking at the "epoxy" spec for removing Eventlet from oslo.service (https://specs.openstack.org/openstack/oslo-specs/specs/epoxy/remove-eventle…) the very top line is a link to search blueprints.launchpad.net. Following that link it seems like there is no blueprint for removing eventlet from oslo.service, so does the spec itself (with the proposed milestones) represent the current plan? Separately, is there somewhere that shows the progress on the threading backend for oslo.service? I see it exists, are there any limitations on the current implementation? Thanks, Chris

2 1

[ops][nova][neutron] Routed provider networking and physnet port scheduling
by Nathan Harper 04 Sep '25

04 Sep '25

Hi all, We have been looking at building some routed provider networks, following this documentation: https://docs.openstack.org/neutron/latest/admin/config-routed-networks.html In this scenario we have 4 racks, and have defined physnets for each rack and assigned SRIOV interfaces for each. We then have created a multisegment network, with a segment associated with each physnet. We get the expected resource provider in placement containing only these hypervisors. When scheduling instances onto this network, the allocation candidates are any hypervisors in racks 1-4 (openstack filters the hypervisors using the aggregates for each segment that neutron creates). However, during instance build the pci device request sent to nova-compute always contains the physnet of the same segment. Debugging the builds, we ended up here: https://opendev.org/openstack/nova/src/branch/master/nova/network/neutron.p…, with: # TODO(vladikr): Additional work will be required to handle the # case of multiple vlan segments associated with different # physical networks. Which originates from this commit: https://opendev.org/openstack/nova/commit/b9d9d96a407db5a2adde3aed81e61cc95… This suggests that despite the documentation describing using multiple VLAN backed segments in this fashion, this has never worked? Or are we missing something? Has anyone successfully used routed provider networks? -- Regards, Nathan Harper Principal Engineer – Cloud Development Platform Engineering nathanh(a)graphcore.ai<mailto:nathanh@graphcore.ai> www.graphcore.ai →<http://www.graphcore.ai/> ** We have updated our privacy policy, which contains important information about how we collect and process your personal data. To read the policy, please click here<http://www.graphcore.ai/privacy> ** This email and its attachments are intended solely for the addressed recipients and may contain confidential or legally privileged information. If you are not the intended recipient you must not copy, distribute or disseminate this email in any way; to do so may be unlawful. Any personal data/special category personal data herein are processed in accordance with UK data protection legislation. All associated feasible security measures are in place. Further details are available from the Privacy Notice on the website and/or from the Company. Graphcore Limited (registered in England and Wales with registration number 10185006) is registered at, 1 Maple Road, Bramhall, Stockport, Cheshire, UK, SK7 2DH. This message was scanned for viruses upon transmission. However Graphcore accepts no liability for any such transmission.

3 7

[release][horizon][ironic] Deliverables potentially needing a refresh before final Flamingo release
by Thierry Carrez 03 Sep '25

03 Sep '25

Quick reminder that for deliverables following the cycle-with-intermediary model, the release team will use the latest Flamingo release available on release week. The following deliverables have done a Flamingo release, but it was not refreshed in the last two months: - horizon (25.4.0 was released 2025-05-27) - ironic-python-agent-builder (6.1.0 was released 2025-06-10) - networking-baremetal (6.6.0 was released 2025-06-10) You should consider making a new one very soon, so that we don't use an outdated version for the final release. -- Thierry Carrez (ttx)

1 0

#eventlet-removal - Progress & Updates - Flamingo Past Milestone 3
by Herve Beraud 03 Sep '25

03 Sep '25

TL;DR: We just recently passed Flamingo's milestone 3 and since the last ML update we observed tremendous progress. Ironic, Barbican, Heat completed their migration. Futurist has been improved with new useful features for threading mode. The migration timeline has been adjusted to match Nova's dual mode support. PTG is under preparation. Statistics show good progress. Eventlet now supports Python 3.14. ## OpenStack Updates From a statistical perspective: - almost 17% of the occurences of the runtime code initially impacted by Eventlet have been tackled — outside of code dedicated to test, doc, releasenotes, etc; - if we include all the spectrum of occurrences to migrate — code, tests, doc, examples — it represent ~14% of the entire code base already migrated; - more than 40% of all impacted repositories have made some progress in link with the migration; - 13 projects have been fully migrated since the beginning; - more than 332 patches related to the eventlet migration have been submitted to gerrit. From the teams perspective, we can highlight Ironic completed its migration, for the occasion wrote an excellent write-up [1] — thanks Julia — I strongly encourage you to read it. Barbican [2] and heat [3] successfully completed their migrations too. They are now fully threading based. Dmitry in collaboration with the Ironic team implemented a DynamicPoolExecutor in Futurist [4]. It helps replace dynamic GreenPool. Oslo.service's backend system is now documented [5]. There is still ongoing work on several OpenStack deliverables: Neutron, Nova, Manila, Magnum, Mistral, Watcher, Designate, Trove, etc. All these teams demonstrated awesome progress. The migration timeline has been adjusted at the governance level to match Nova's dual mode support [6]. There is ongoing preparation of the PTG sessions. I think there will be a short slot during one of the TC sessions, and surely a fully dedicated one hour slot to host cross team open discussions. ## Eventlet Updates The support of Python 3.14 has been introduced within Eventlet 0.40.2. A vulnerability (CVE-2025-58068, CVSS 6.3) in Eventlet’s WSGI parser allowing HTTP Request Smuggling (bypass controls, cache poisoning, user targeting) has been found. It has been fixed within Eventlet 0.40.3. A security advisory has been published [7]. ## Call to Action That would be worth considering introducing small experiments as opportunities to identify or learn any weaknesses in new threading architectural models. That could start by preparing and performing some perf scale testing at your deliverables levels. That will help you to define the right scaling configuration for your deliverables. You can draw inspiration from Neutron's rally jobs [8] and from Ironic's scripting created for benchmark purposes [9]. More than a year ago, Dan sparked the performance testing topic idea [10], that's the right time to consider it more deeply. If you do not start the migration of your deliverables, I'd encourage you to plan and prioritize it as soon as possible. Time flies and the later your migration starts the harder it will be. Python 3.15 comes with its share of breaking changes [11] so I'd not suggest waiting for that time. If you are scheduling a PTG session on your side about Eventlet, then please let us know by updating the eventlet removal wiki page [12]. If your service is now migrated, I'd invite you to tag the launchpad bugs which were related to Eventlet, and, if it makes sense to close them. You are now entering a clean phase. ## Final Thoughts During Flamingo we observed tremendous progress, and we are now going straight toward the final release of Flamingo. The PTG, and Gazpacho that will be the logical continuation of the jobs already done. Flamingo will mark a significant release due to the fully migrated bricks and services. They will allow us to enter a beneficial feedback loop. The migration path is now well cleared by all the previous actions and changes applied into OpenStack. Postponing the beginning of the migration will make your life harder. We want to prevent this from happening to you. Your journey start here https://removal.eventlet.org/ If you need information join-us on the #openstack-eventlet-removal OFTC channel. Thanks to all the people who made this migration possible until now. Thanks for your attention. [1] https://ironicbaremetal.org/blog/coming-soon-threading/ [2] https://review.opendev.org/c/openstack/barbican/+/955301 [3] https://review.opendev.org/c/openstack/heat/+/952651 [4] https://docs.openstack.org/futurist/latest/reference/index.html#futurist.Dy… [5] https://docs.openstack.org/oslo.service/latest/user/backend.html [6] https://review.opendev.org/c/openstack/governance/+/952903 [7] https://github.com/advisories/GHSA-hw6f-rjfj-j7j7 [8] https://opendev.org/openstack/neutron/src/branch/master/rally-jobs [9] https://opendev.org/openstack/ironic/src/branch/master/tools/benchmark [10] https://review.opendev.org/c/openstack/governance/+/902585/comment/979db3f6… [11] https://docs.python.org/es/dev/whatsnew/3.15.html#threading [12] https://wiki.openstack.org/wiki/Eventlet-removal#Project-specific_events -- Hervé Beraud Principal Software Engineer at Red Hat irc: hberaud https://github.com/4383/

1 0

[keystone][ops] Upgrade to 2025.1 and "corner cases"
by Dmitriy Rabotyagov 02 Sep '25

02 Sep '25

Hey folks, I wanted to raise awareness of operators regarding Keystone upgrade to Epoxy (2025.1), as found that existing release notes are slightly more vague about corner case definition. During analysis, it appeared that a lot of users (and under "a lot" I mean 4 figures number) in my really old deployments (which were deployed during Newton), still in use passwords hashed with sha512_crypt which has been dropped in 2025.1 [1]. As this was referenced as a "corner case" in upgrade docs, it may not bring enough attention to this matter reading notes, while sha512_crypt removal is mentioned in "Other" section which I personally missed when analyzing upgrade requirements. So I would highly recommend to ensure that all your users are using supported hashing algorithms before the upgrade to Epoxy, and inform them to reset their passwords if they don't. You can list users who are using unsupported hashing algorithm using following MySQL query: SELECT distinct l_u.user_id FROM keystone.local_user AS l_u JOIN keystone.password AS hash ON l_u.id = hash.local_user_id WHERE (hash.password_hash LIKE '$6$%' OR hash.password_hash LIKE '$5$%') AND hash.expires_at i s null; Hope this helps somebody to save some time in the future. [1] https://opendev.org/openstack/keystone/commit/4a4137d5f77ced3f4f011846fb9c2…

7 13

[Nova&Neutron] pagination returns an http, not https href link
by Chang Xue 02 Sep '25

02 Sep '25

Hello, we just migrated using new openstack CLI tools, and when using pagination for both Nova and Neutron, we noticed that they are returning http href link although they are expecting https, causing failure: ``` openstack port list Failure: Unable to establish connection to http://openstack....example.com:9696/v2.0/ports: ('Connection aborted.', RemoteDisconnected('Remote end closed connection without response')). Retrying in 0.5s.1 retries left Unable to establish connection to http://openstack.....example.com:9696/v2.0/ports: ('Connection aborted.', RemoteDisconnected('Remote end closed connection without response')) ``` Is this a bug in Nova/Neutron? I tried other services like Heat, Keystone, etc, and they either returning https href links or just take relative path without schema/host. Thanks, Chang

3 10

[neutron][ovn] Logical Port Statistics
by James Denton 02 Sep '25

02 Sep '25

Hello all, Is anyone aware of a method to gather statistics (bytes in/out, packets, etc.) for logical router ports or similar when using ML2/OVN? I understand neutron-metering-agent parity is currently a feature gap, but I’m curious if there’s some OVN-native functionality that can provide those details. The ask is to provide a bytes-in/out counter for tenant routers, specifically on the external interface(s). Thanks, James Get Outlook for Mac <https://aka.ms/GetOutlookForMac>

3 3

[release][PTLs] Reminder to 2025.2 Flamingo Cycle highlights
by Elõd Illés 02 Sep '25

02 Sep '25

Hi, Let me remind you that this week is the week when 2025.2 Flamingo's Cycle highlights should be finalized (now that the Feature Freeze deadline has passed) so that they can be included in release marketing preparations. Thanks, Előd Illés irc: elodilles @ #openstack-release

1 0

[magnum] Proposing Scott Davidson as magnum-capi-helm core reviewer
by Michał Nasiadka 01 Sep '25

01 Sep '25

Hello, I’d like to propose Scott Davidson as a core reviewer for magnum-capi-helm repository. His insightful and timely reviews have been helping to drive fixes and new features - and it would be great to have him as part of the core reviewers team. Best regards, Michal Nasiadka

3 3

[tc][all] OpenStack Technical Committee Weekly Summary and Meeting Agenda (2025.2/R-4)
by Goutham Pacha Ravi 01 Sep '25

01 Sep '25

Hello Stackers, We're in the final leg of our release journey with the 2025.2 "Flamingo" release [1]. Last week, we observed a feature freeze across all OpenStack deliverables that follow a "cycle-with-rc" [2] release model. Project teams are now preparing their release candidates, which will be posted next week. Polls have opened to elect a Project Team Lead in the Horizon (OpenStack Dashboard) project, as well as to elect four representatives on the OpenStack Technical Committee. Polls will close on September 17th, 2025, at 23:45 UTC [2]. Election officials observed that a good portion of the electorate would not receive their ballots because they haven't signed up to receive emails from the election system: CIVS. Please do ensure that your preferred email on gerrit has been used to opt in to CIVS emails. If you opt in newly, you will not receive an email ballot; instead, you'll see a pending poll invitation on CIVS: https://civs1.civs.us/cgi-bin/opt_in.pl In the past week, the Watcher project team has constituted a new set of project liaisons, and election officials have let the TC know that four OpenStack project teams have not had any PTL nominees. These are Monasca, OpenStack Charms, Venus, and Vitrage. We expect to make some changes shortly. === Weekly Meeting === The OpenStack Technical Committee had its last weekly meeting over IRC on August 26th, 2025 [3]. We had a lively discussion on several key topics. We're closing out the 'Migrate from WSGI scripts to module paths' goal [4] as complete. We also discussed the status of the Monasca project team [5]. It's still a point of contention with some folks wanting to move forward with its retirement while others want to give a new contributor a chance to get it running again. We've decided to defer a final decision to allow for more discussion on Gerrit and to give the new contributor a chance to make some progress. Another important topic we covered was the impact of the recent OIF membership renewals on the ongoing TC elections. With a significant number of potential voters not renewing their memberships, we are concerned about potential disenfranchisement. We hope to urge renewals past these elections and share a follow-up regarding the elections to the OIF Board. Finally, we discussed a proposed "phone-home" patch in the Cinder project [6]. While the feature technically sends data to an external storage system rather than an OpenStack service, there was a consensus that any "call-home" functionality should be opt-in, not enabled by default. This is a matter of respecting user privacy and not making assumptions about an operator's environment. Jon Bernard (jbernard) plans to draft a formal resolution to address this, and we'll advise on the process. The next meeting of the OpenStack TC is on Tuesday, September 2nd, 2025. This meeting will be hosted simultaneously on Meetpad (video) and IRC (#openstack-tc on OFTC) at 1700 UTC. Please find the agenda and call details on the meeting's wiki page [7]. I hope you'll be able to join us there! === Governance Proposals === ==== Merged ==== - Use DPL model for Watcher project leadership for 2026.1 release | https://review.opendev.org/c/openstack/governance/+/958085 ==== Open For Review ==== - Retire Metalsmith project from bare metal program | https://review.opendev.org/c/openstack/governance/+/958297 - Show inactive project status in project.yaml | https://review.opendev.org/c/openstack/governance/+/958229 - 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 "Migrate from wsgi scripts" goal as completed | https://review.opendev.org/c/openstack/governance/+/958817 === Upcoming Events === - 2025-09-06: OpenInfra Days, Kenya: https://www.meetup.com/kenya-openinfra-user-group/ - 2025-09-17: OpenStack TC and Horizon project elections conclude: https://governance.openstack.org/election/ - 2025-09-09: OIF Board Monthly meeting: https://board.openinfra.org/ - 2025-10-01: OpenStack 2026.1 "Flamingo" release day - 2025-10-03: OpenStack's Birthday Meetup, Austin: https://www.meetup.com/openinfra-austin/events/310508680 - 2025-10-17: OpenInfra Summit, Paris-Saclay: https://summit2025.openinfra.org/ - 2025-10-27: OpenInfra PTG: https://openinfra.org/ptg/ Thank you very much for reading! On behalf of the OpenStack TC, Goutham Pacha Ravi (gouthamr) OpenStack TC Chair [1] 2025.2 "Flamingo" Release Schedule: https://releases.openstack.org/flamingo/schedule.html [2] "cycle-with-rc" release model: https://releases.openstack.org/reference/release_models.html#cycle-with-rc [3] TC Meeting IRC Log, August 26th 2025: https://meetings.opendev.org/meetings/tc/2025/tc.2025-08-26-17.00.html [4] Community Goal to update wsgi configuration: https://governance.openstack.org/tc/goals/proposed/migrate-from-wsgi-script… [5] Retiring the Monasca project team: https://review.opendev.org/c/openstack/governance/+/953671 [6] Cinder driver phoning home: https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack… [7] TC Meeting Agenda, September 2nd, 2025: https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Next_Meeting

1 0

[neutron] Bug deputy report (week starting on August 25)
by Elvira Garcia Ruiz 01 Sep '25

01 Sep '25

Hi folks, Here you have the list of bugs reported for Neutron during last week. (Aug 25 - Aug 31) High ------- - https://bugs.launchpad.net/neutron/+bug/2121609 flake8 plugins from neutron-lib are enabled by default, breaking existing projects dependent on it Fix proposed by Takashi Kajinami https://review.opendev.org/c/openstack/neutron-lib/+/958786 - https://bugs.launchpad.net/neutron/+bug/2121649 [n-t-p] Test "test_subport_connectivity" failing randomly in 2025.1 Unassigned. Medium ----------- - https://bugs.launchpad.net/neutron/+bug/2121605 nova and neutron pagination returns an http, not https href link Unassigned Low ------ - https://bugs.launchpad.net/neutron/+bug/2121530 [SR-IOV] Trusted VF port MAC address can be changed from inside the VM Fix proposed by Ralonsoh https://review.opendev.org/c/openstack/neutron/+/958877 Undecided -------------- - https://bugs.launchpad.net/neutron/+bug/2121582 Source / Destination IP address is not respected in firewall group rule FWaaS v2 Unassigned. I will ask mlavalle about how to triage this since it’s ovs-fw related if I understand correctly. Best regards! Elvira

1 0

Setting up HA in OpenStack with Kolla-Ansible (Instance failover across compute nodes)
by Thamanna Farhath 31 Aug '25

31 Aug '25

Hi OpenStack Community, I have installed *Masakari* using Kolla-Ansible, and after that I also installed *HACluster*. However, the HACluster containers are failing and keep exiting. Setup: - 3 controller nodes - Multiple compute nodes - Deployment: Kolla-Ansible My questions are: 1. Do I really need Masakari together with HACluster for instance HA? 2. Is there an alternative or recommended way to deploy HACluster with Kolla-Ansible? 3. Has anyone faced the issue where HACluster containers keep exiting after deployment? Any guidance, troubleshooting tips, or experiences would be very helpful. Thamanna Farhath Associate Engineer R&D mailto:manoj.kumar@zybisys.com thamanna.f(a)zybisys.com https://www.zybisys.com https://in.linkedin.com/company/zybisys https://www.facebook.com/Zybisys/ https://www.instagram.com/ZyBiSys/ https://www.youtube.com/@zybisys https://www.facebook.com/Zybisys/ Disclaimer : The content of this email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to which they are addressed. If you have received this email in error, please notify the sender and remove the messages from your system. If you are not the named addressee, it is strictly forbidden for you to share, circulate, distribute or copy any part of this e-mail to any third party without the written consent of the sender. E-mail transmission cannot be guaranteed to be secured or error free as information could be intercepted, corrupted, lost, destroyed, arrive late, incomplete, or may contain viruses. Therefore, we do not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. The recipient should check this e-mail and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email."

1 0

[all][elections][tc] TC Election Campaigning Kickoff
by Ian Y. Choi 31 Aug '25

31 Aug '25

Developers, The TC Election Campaigning Period has now started[1]. During the next couple days, you are all encouraged to ask the candidates questions about their platforms[2], opinions on OpenStack, community governance, and anything else that will help you to better determine how you will vote. This is the time to raise any issues you wish the future TC to consider, and to evaluate the opinions of the nominees prior to their election. Candidates, Each of you has posted a platform[2], and announced your nomination to the developers. From this point, you are encouraged to ask each other questions about the posted platforms, and begin discussion of any points that you feel are particularly important during the next cycle. While you are not yet TC members, your voices and opinions about the issues raised in your platforms and questions raised by the wider community will help ensure that the future TC has the widest possible input on the matters of community concern, and the electorate has the best information to determine the ideal TC composition to address these and other issues that may arise. [1] https://governance.openstack.org/election/ [2] https://opendev.org/openstack/election/src/branch/master/candidates/2026.1/… Ian Y. Choi & Slawek Kaplonski, on behalf of election officials.

5 4

[release] Release countdown for week R-4, Sep 01 - 05
by Elõd Illés 29 Aug '25

29 Aug '25

Development Focus ----------------- We just passed feature freeze! Until release branches are cut, you should stop accepting featureful changes to deliverables following the cycle-with-rc release model, or to libraries. Exceptions should be discussed on separate threads on the mailing-list, and feature freeze exceptions approved by the team's PTL. Focus should be on finding and fixing release-critical bugs, so that release candidates and final versions of the 2025.2 "Flamingo" deliverables can be proposed, well ahead of the final 2025.2 "Flamingo" release date. General Information ------------------- We are still finishing up processing a few release requests, but the 2025.2 "Flamingo" release requirements are now frozen. If new library releases are needed to fix release-critical bugs in 2025.2 "Flamingo", you must request a Requirements Freeze Exception (RFE) from the requirements team before we can do a new release to avoid having something released in 2025.2 "Flamingo" that is not actually usable. This is done by posting to the openstack-discuss mailing list with a subject line similar to: [$PROJECT][requirements] RFE requested for $PROJECT_LIB Include justification/reasoning for why a RFE is needed for this lib. If/when the requirements team OKs the post-freeze update, we can then process a new release. A soft String freeze is now in effect, in order to let the I18N team do the translation work in good conditions. In Horizon and the various dashboard plugins, you should stop accepting changes that modify user-visible strings. Exceptions should be discussed on the mailing-list. By September 26th, 2025 this will become a hard string freeze, with no changes in user-visible strings allowed. Actions ------- stable/2025.2 branches should be created soon for all not-already-branched libraries. You should expect 2-3 changes to be proposed for each: a .gitreview update, a reno update (skipped for projects not using reno), and a tox.ini constraints URL update. Please review those in priority so that the branch can be functional ASAP. The Prelude section of reno release notes is rendered as the top level overview for the release. Any important overall messaging for 2025.2 "Flamingo" changes should be added there to make sure the consumers of your release notes see them. Upcoming Deadlines & Dates -------------------------- RC1 deadline: September 12th, 2025 (R-3 week) Final RC deadline: September 26th, 2025 (R-1 week) Final 2025.2 "Flamingo" release: October 1st, 2025 OpenInfra Summit Europe: October 17th-19th, 2025 Előd Illés irc: elodilles @ #openstack-release

1 0

[release][swift][ironic] Deliverables missing Flamingo releases
by Thierry Carrez 29 Aug '25

29 Aug '25

Hi everyone, Quick reminder that we'll need a release very soon for a number of deliverables following a cycle-with-intermediary release model but which have not done *any* release yet in the 2025.2 Flamingo cycle: bifrost ironic-inspector ironic-prometheus-exporter ironic-ui networking-generic-switch swift Those should be released ASAP, and in all cases before September 12th, so that we have a release to include in the final 2025.2 Flamingo release. -- Thierry Carrez (ttx)

1 0

[manila] 2025.2 Flamingo bugsquash Sep 2nd - 4th
by Carlos Silva 28 Aug '25

28 Aug '25

Hello, zorillas and interested stackers. The second bug squash is happening next week and we will be focusing on closing in progress bugs and doing some triaging in our bug backlog. Vida (vhari) worked on the bugsquash etherpad [1]. In case you'd like to work on a bug that is not on the list, please add it. The kick-off meeting will happen on Sep 2nd at 1400 UTC on meetpad [2] and the Sep 4th manila weekly meeting slot will be used for the bugsquash. Goutham and Vida will lead the bugsquash. In case you intend to participate, please add the meeting's .ics file [3] to the calendar of your preference. [1] https://etherpad.opendev.org/p/manila-flamingo-m2-bugsquash [2] https://meetpad.opendev.org/p/manila-flamingo-m2-bugsquash [3] https://gist.github.com/silvacarloss/21451503aef7441c0e752b07c1b2091b Thank you, carloss

1 0

[ironic] Sept 1, 2025 meeting cancelled?
by Jay Faulkner 28 Aug '25

28 Aug '25

Hey all, September 1 2025 is Labor Day, and most US folks have the day off. For this reason, we're should cancel this weeks' meeting. Thanks, Jay Faulkner

1 0

Need information
by engineer2024 28 Aug '25

28 Aug '25

Hi Folks, In the context of ovn, the way the ovn agents like ovn controller, ovn metadata etc, broadcast their aliveness status is by updating certain values in the local ovs db tables to show they are alive , which is then picked up by the ovn controller on that node and it updates the southbound db which passes on to the north daemon and it informs neutron. is this the correct understanding of how ovn agent check works ? i am facing an issue, where three neutron server container hosts are marked as 'gw as a chassis' to serve dhcp and neutron metadata requests for sriov based vms. these are grouped into a single ha chassis group with a priority no for each chassis. when I stopped one of the ovn metadata agents on an active chassis, the ovn is not changing the chassis entry of that sriov port in the port binding table of the sb. it is still showing the old chassis entry. I checked for any updates in the ovn controller logs of the new active and passive chassis' . but nothing in the logs. is this a bug or some internal communication is not happening among the chassis' ovn controllers, northd , nb and sb ? Thanks elinux

1 0

[ironic] Future of Metalsmith
by Jay Faulkner 28 Aug '25

28 Aug '25

For almost two years, the Ironic team has had a "maintenance mode" message on the Metalsmith readme: "Please note the Metalsmith project is in maintenance mode and it's functionality is slowly being introduced into Ironic's API and usual clients. No additional features are expected to be added to Metalsmith directly." CI is currently not passing on this repository, and as far as I can tell there are no engaged users of this project upstream, and no current maintainers of Ironic invested in keeping this project afloat. I propose we retire the metalsmith project and exclude it from the Flamingo release. Are there any objections? Thanks, JayF

4 4

Setting up HA in OpenStack with Kolla-Ansible (Instance failover across compute nodes)
by SARAN RAJ 28 Aug '25

28 Aug '25

Hi OpenStack Community, I have installed **Masakari** using Kolla-Ansible, and after that I also installed **HACluster**. However, the HACluster containers are failing and keep exiting. Setup: - 3 controller nodes - Multiple compute nodes - Deployment: Kolla-Ansible My questions are: 1. Do I really need Masakari together with HACluster for instance HA? 2. Is there an alternative or recommended way to deploy HACluster with Kolla-Ansible? 3. Has anyone faced the issue where HACluster containers keep exiting after deployment? Any guidance, troubleshooting tips, or experiences would be very helpful. SARAN RAJ Associate Software Engineer mailto:manoj.kumar@zybisys.com saranraj.m(a)zybisys.com https://www.zybisys.com https://in.linkedin.com/company/zybisys https://www.facebook.com/Zybisys/ https://www.instagram.com/ZyBiSys/ https://www.youtube.com/@zybisys https://www.facebook.com/Zybisys/ Disclaimer : The content of this email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to which they are addressed. If you have received this email in error, please notify the sender and remove the messages from your system. If you are not the named addressee, it is strictly forbidden for you to share, circulate, distribute or copy any part of this e-mail to any third party without the written consent of the sender. E-mail transmission cannot be guaranteed to be secured or error free as information could be intercepted, corrupted, lost, destroyed, arrive late, incomplete, or may contain viruses. Therefore, we do not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. The recipient should check this e-mail and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email."

1 0

[all][elections][ptl][tc] Conbined PTL/TC 2026.1 cycle Election Voting Kickoff
by Ian Y. Choi 27 Aug '25

27 Aug '25

Polls for PTL and TC elections are now open and will remain open for you to cast your vote until Sep 17, 2025 23:45 UTC. We are selecting 4 TC members, and are having PTL elections for Horizon. Please rank all candidates in your order of preference. You are eligible to vote in the TC election if you are a Foundation individual member[0] that also has committed to any official project team's deliverable repositories[1] over the Sep 13, 2024 00:00 UTC - Aug 20, 2025 00:00 UTC timeframe (2025.1 to 2025.2) or if you are in the list of extra-acs[2] for any official project team. You are eligible to vote in a PTL election if you are a Foundation individual member[0] and had a commit in one of that team's deliverable repositories[1] over the Sep 13, 2024 00:00 UTC - Aug 20, 2025 00:00 UTC timeframe (2025.1 to 2025.2) or if you are in that team's list of extra-acs[2]. If you are eligible to vote in an election, you should find your email with a link to the Condorcet Internet Voting Service (CIVS) page to cast your vote in the inbox of your Gerrit preferred email[3]. What to do if you don't see the email and have a commit in at least one of the projects having an election: * due to a new CIVS policy, to get the email from poll supervisors, you must opt in to email communication opt in with your Gerrit email address at: https://civs1.civs.us/cgi-bin/opt_in.pl * eligible voters who opt in to email communication late can see a pending poll invitation and vote until Sep 17, 2025 23:45 UTC. * check the trash or spam folders of your Gerrit Preferred Email address, 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 the project's deliverable repos[0] and email the election officials[4]. If we can confirm that you are entitled to vote, we will add you to the voters list for the appropriate election. Our democratic process is important to the health of OpenStack, please exercise your right to vote! Candidate statements/platforms can be found linked to Candidate names on this page: https://governance.openstack.org/election/ Happy voting, [0] https://www.openstack.org/community/members/ [1] The list of the repositories eligible for electoral status: https://opendev.org/openstack/governance/src/tag/0.19.0/reference/projects.… [2] Look for the extra-acs element in [1] [3] 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. [4] https://governance.openstack.org/election/#election-officials

1 0

[oslo] status of eventlet removal for oslo.service?
by Chris Friesen 27 Aug '25

27 Aug '25

Hi everyone, Looking at the "epoxy" spec for removing Eventlet from oslo.service (https://specs.openstack.org/openstack/oslo-specs/specs/epoxy/remove-eventle…) the very top line is a link to search blueprints.launchpad.net. Following that link it seems like there is no blueprint for removing eventlet from oslo.service, so does the spec itself (with the proposed milestones) represent the current plan? Separately, is there somewhere that shows the progress on the threading backend for oslo.service? I see it exists, are there any limitations on the current implementation? Thanks, Chris

2 1

[ops] [all] One Week until 2025 OpenStack User Survey Deadline
by Allison Price 27 Aug '25

27 Aug '25

Hi everyone, I wanted to remind everyone that next Friday, August 29 is the deadline to complete this year’s OpenStack User Survey. If you haven’t taken it before, this is a great opportunity to help channel feedback to the upstream community while helping us understand the global OpenStack footprint better. It should only take ~20 minutes and is incredibly valuable. If you have taken it before, it’s still important to review and update your data. This should only take a few minutes. https://openstack.org/usersurvey Thank you all! Cheers, Allison

2 2

[ironic][magnum][tacker][telemetry][venus][vitrage] broken gate on master branch
by Elõd Illés 27 Aug '25

27 Aug '25

Hi teams in $SUBJECT, The release team usually checks the gate health of deliverables that did not have merged patches recently and it seems you have a project with broken gate: https://review.opendev.org/q/topic:release-health-check-flamingo+is:open Could you please check and fix the gate so that we don't release 2025.2 Flamingo with a broken state. Thanks in advance, Előd Illés irc: elodilles @ #openstack-release

4 3

[openstack-magnum ui] Cannot choose an external network ID when creating a cluster template
by Nguyễn Hữu Khôi 27 Aug '25

27 Aug '25

Hello, When I create a cluster template, I cannot choose an external network ID, it disappears from horizon. My env: Ubuntu 22.04 Openstack 2024.2 Thank you. Regards Nguyen Huu Khoi

3 2

[tc][all] OpenStack Technical Committee Weekly Summary and Meeting Agenda (2025.2/R-5)
by Goutham Pacha Ravi 25 Aug '25

25 Aug '25

Hello Stackers, We're nearing the feature freeze date for the 2025.2 "Flamingo" release [1]. It's on Thursday, August 28, 2025. In the past week, we wrapped up the nomination window for the upcoming community elections [2]. We are currently observing a week of campaigning for TC positions where you may ask the candidates to share their views on any subject pertaining to the community. Their profiles and platforms are posted on the elections website [3]. The elections will begin on August 27, 2025, and will wrap up in three weeks. Also in the past week, the TC defined the tested runtimes and operating systems across OpenStack projects for the upcoming 2026.1 "Gazpacho" release [4]. Our hope is that project teams will prioritize technical debt, such as dropping the use of the eventlet library per our envisioned timeline, so we can match these runtime changes. === Weekly Meeting === The last weekly meeting of the OpenStack Technical Committee occurred on August 19, 2025 [5]. The main topics of discussion were updates on the 2026.1 elections, the retirement process for Monasca repositories, and the ongoing issues with the Zuul CI system. A good portion of the meeting was dedicated to reviewing the election status, where we discussed the low engagement from some project teams with the election process. The change in OIF membership semantics affected several PTL and TC nominations and has resulted in a significantly reduced electorate. The meeting also addressed the Monasca repository retirement, where the path forward for deleting unmaintained branches and merging "empty" changes was discussed. Lastly, the meeting briefly touched on the impact of a recent Ansible version update on Zuul, which has caused job failures for jobs running on older Ubuntu nodes and older Python versions. If you're affected, please do consider migrating these jobs, or bring your concerns to OFTC's #opendev channel. The next meeting of the OpenStack Technical Committee is today, August 26, 2025, at 1700 UTC. This meeting will be hosted over IRC in OFTC's #openstack-tc channel. Please find the agenda and other details on the meeting's wiki [6]. I hope you'll be able to join us there. === Governance Proposals === ==== Merged ==== - Define testing runtime for 2026.1 release | https://review.opendev.org/c/openstack/governance/+/957199 ==== Open for Review ==== - Retire metalsmith project from bare metal program | https://review.opendev.org/c/openstack/governance/+/958297 - Show inactive project status in project.yaml | https://review.opendev.org/c/openstack/governance/+/958229 - Retire Monasca project | https://review.opendev.org/c/openstack/governance/+/953671 - Use DPL model for watcher project leadership for 2026.1 release | https://review.opendev.org/c/openstack/governance/+/958085 - Require declaration of affiliation from TC Candidates | https://review.opendev.org/c/openstack/governance/+/949432 === Upcoming Events === - 2025-08-26: OpenInfra Days, Korea: https://2025.openinfradays.kr/ - 2025-08-27: OpenStack 2026.1 Election Voting begins: https://governance.openstack.org/election/ - 2025-08-28: Feature Freeze deadline, Milestone-3 of the Flamingo release [1] - 2025-08-29: Colombia OpenInfra User Group Meetup: https://www.meetup.com/colombia-openinfra-user-group/events/307096751/ - 2025-09-09: OIF Board Monthly meeting: https://board.openinfra.org/ - 2025-10-17: OpenInfra Summit, Paris-Saclay: https://summit2025.openinfra.org/ Thank you very much for reading! On behalf of the OpenStack TC, Goutham Pacha Ravi (gouthamr) OpenStack TC Chair [1] 2025.2 "Flamingo" Release Schedule: https://releases.openstack.org/flamingo/schedule.html [2] Nominations close email: https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack… [3] 2026.1 TC Candidates: https://governance.openstack.org/election/#tc-candidates [4] Tested Runtimes for Gazpacho: https://governance.openstack.org/tc/reference/runtimes/2026.1 [5] TC Meeting IRC Log, Aug 19, 2025: https://meetings.opendev.org/meetings/tc/2025/tc.2025-08-19-17.00.html [6] TC Meeting Agenda, Aug 26, 2025: https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Next_Meeting

1 0

[publiccloud-sig] Public Cloud SIG meeting d.d. 27 August
by Kees Meijs | Nefos 25 Aug '25

25 Aug '25

Hello Stackers, Upcoming Wednesday (that's 27 August) 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 See you then! 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

[ops][largescale-sig][scientific-sig] Ops Radio Hour on August 22, 2025
by Ildiko Vancsa 23 Aug '25

23 Aug '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 __August 22nd, 2025 at 1300UTC.__ 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. Topics the next gathering will dive into: - (SWIFT) Compliance processes - GPUs - VMware migration - vTPM (live migrations or not?): reboot, start - Keystone security param bug - https://bugs.launchpad.net/keystone/+bug/2117217 - Consolidating Ops IRC and Matrix channels What other topics should we add to the agenda? 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> + 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 August 22nd! Bets Regards, Ildikó [1] https://wiki.openstack.org/wiki/Operations/Meetups

1 1

[cinder-backup]cinder backup show progress percentage
by Nguyễn Hữu Khôi 23 Aug '25

23 Aug '25

Hello. I would like to know if we have some methods to show backup progress percentage. I see this but it is old and work only with Swift. https://specs.openstack.org/openstack/cinder-specs/specs/kilo/backup-notifi… Nguyen Huu Khoi

1 0

[freezer]backup with cindernative mode
by Nguyễn Hữu Khôi 23 Aug '25

23 Aug '25

Hello. I am using openstack 2025.1 and freezer 2025.1 to test. I can backup and restore using cinder. but I won't do it with cindernative, could you tell me that we need swiff to use this mode? This is my command: freezer-agent --mode cindernative --cindernative-vol-id fcc22b9f-ef01-4d16-bfde-83af6312bce9 --log-file k.log --debug Critical Error: Endpoint for object-store not found - have you specified a region? Thank much. Nguyen Huu Khoi

2 11

Keystone "TokenNotFound: Failed to validate token"
by Marc Vorwerk 23 Aug '25

23 Aug '25

Hi all, I am running into an issue with our OpenStack Kolla-Ansible deployment (Release 2024.1, Keystone 25.0.1) where Keystone logs are being flooded (18k per day) with TokenNotFound: Failed to validate token stack traces[1]. From the traceback, it seems these requests are attempting to validate tokens that have already been revoked. The majority of these come from Nova and Cinder, but the request_id from Keystone does not appear in their logs. Instead of finding the matching requests in Nova or Cinder logs, I only see InvalidToken: Token authorization failed messages[2]. Most of the time, the platform does not show any user-visible issues in these areas, although occasional failures can be observed. Could this indicate an issue with token caching or revocation list synchronization between services? Memcached looks fine. Any ideas what could be triggering this behavior are welcome. If you need more Information please let me know. Thanks in advance. Best regards, Marc [1] ERROR keystone.server.flask.application [None req-326cbeaa-a363-4a82-b45b-498d6f2ad338 b30e2d031b6a4851b69f9b1791716919 d977f9d63d3043288bed6e549e507c9a - - default default] Failed to validate token: keystone.exception.TokenNotFound: Failed to validate token ERROR keystone.server.flask.application Traceback (most recent call last): ERROR keystone.server.flask.application File "/var/lib/kolla/venv/lib/python3.10/site-packages/flask/app.py", line 870, in full_dispatch_request ERROR keystone.server.flask.application rv = self.dispatch_request() ERROR keystone.server.flask.application File "/var/lib/kolla/venv/lib/python3.10/site-packages/flask/app.py", line 855, in dispatch_request ERROR keystone.server.flask.application return self.ensure_sync(self.view_functions[rule.endpoint])(**view_args) # type: ignore[no-any-return] ERROR keystone.server.flask.application File "/var/lib/kolla/venv/lib/python3.10/site-packages/flask_restful/__init__.py", line 489, in wrapper ERROR keystone.server.flask.application resp = resource(*args, **kwargs) ERROR keystone.server.flask.application File "/var/lib/kolla/venv/lib/python3.10/site-packages/flask/views.py", line 110, in view ERROR keystone.server.flask.application return current_app.ensure_sync(self.dispatch_request)(**kwargs) # type: ignore[no-any-return] ERROR keystone.server.flask.application File "/var/lib/kolla/venv/lib/python3.10/site-packages/flask_restful/__init__.py", line 604, in dispatch_request ERROR keystone.server.flask.application resp = meth(*args, **kwargs) ERROR keystone.server.flask.application File "/var/lib/kolla/venv/lib/python3.10/site-packages/keystone/api/auth.py", line 285, in get ERROR keystone.server.flask.application ENFORCER.enforce_call(action='identity:validate_token') ERROR keystone.server.flask.application File "/var/lib/kolla/venv/lib/python3.10/site-packages/keystone/common/rbac_enforcer/enforcer.py", line 422, in enforce_call ERROR keystone.server.flask.application subj_token_target_data = cls._extract_subject_token_target_data() ERROR keystone.server.flask.application File "/var/lib/kolla/venv/lib/python3.10/site-packages/keystone/common/rbac_enforcer/enforcer.py", line 261, in _extract_subject_token_target_data ERROR keystone.server.flask.application token = PROVIDER_APIS.token_provider_api.validate_token( ERROR keystone.server.flask.application File "/var/lib/kolla/venv/lib/python3.10/site-packages/keystone/common/manager.py", line 110, in wrapped ERROR keystone.server.flask.application __ret_val = __f(*args, **kwargs) ERROR keystone.server.flask.application File "/var/lib/kolla/venv/lib/python3.10/site-packages/keystone/token/provider.py", line 147, in validate_token ERROR keystone.server.flask.application self._is_valid_token(token, window_seconds=window_seconds) ERROR keystone.server.flask.application File "/var/lib/kolla/venv/lib/python3.10/site-packages/keystone/token/provider.py", line 201, in _is_valid_token ERROR keystone.server.flask.application self.check_revocation(token) ERROR keystone.server.flask.application File "/var/lib/kolla/venv/lib/python3.10/site-packages/keystone/common/manager.py", line 110, in wrapped ERROR keystone.server.flask.application __ret_val = __f(*args, **kwargs) ERROR keystone.server.flask.application File "/var/lib/kolla/venv/lib/python3.10/site-packages/keystone/token/provider.py", line 138, in check_revocation ERROR keystone.server.flask.application return self.check_revocation_v3(token_values) ERROR keystone.server.flask.application File "/var/lib/kolla/venv/lib/python3.10/site-packages/keystone/common/manager.py", line 110, in wrapped ERROR keystone.server.flask.application __ret_val = __f(*args, **kwargs) ERROR keystone.server.flask.application File "/var/lib/kolla/venv/lib/python3.10/site-packages/decorator.py", line 232, in fun ERROR keystone.server.flask.application return caller(func, *(extras + args), **kw) ERROR keystone.server.flask.application File "/var/lib/kolla/venv/lib/python3.10/site-packages/dogpile/cache/region.py", line 1632, in get_or_create_for_user_func ERROR keystone.server.flask.application return self.get_or_create( ERROR keystone.server.flask.application File "/var/lib/kolla/venv/lib/python3.10/site-packages/dogpile/cache/region.py", line 1092, in get_or_create ERROR keystone.server.flask.application with Lock( ERROR keystone.server.flask.application File "/var/lib/kolla/venv/lib/python3.10/site-packages/dogpile/lock.py", line 185, in __enter__ ERROR keystone.server.flask.application return self._enter() ERROR keystone.server.flask.application File "/var/lib/kolla/venv/lib/python3.10/site-packages/dogpile/lock.py", line 94, in _enter ERROR keystone.server.flask.application generated = self._enter_create(value, createdtime) ERROR keystone.server.flask.application File "/var/lib/kolla/venv/lib/python3.10/site-packages/dogpile/lock.py", line 178, in _enter_create ERROR keystone.server.flask.application return self.creator() ERROR keystone.server.flask.application File "/var/lib/kolla/venv/lib/python3.10/site-packages/dogpile/cache/region.py", line 1046, in gen_value ERROR keystone.server.flask.application created_value = creator( ERROR keystone.server.flask.application File "/var/lib/kolla/venv/lib/python3.10/site-packages/keystone/token/provider.py", line 134, in check_revocation_v3 ERROR keystone.server.flask.application PROVIDERS.revoke_api.check_token(token_values) ERROR keystone.server.flask.application File "/var/lib/kolla/venv/lib/python3.10/site-packages/keystone/common/manager.py", line 110, in wrapped ERROR keystone.server.flask.application __ret_val = __f(*args, **kwargs) ERROR keystone.server.flask.application File "/var/lib/kolla/venv/lib/python3.10/site-packages/keystone/revoke/core.py", line 137, in check_token ERROR keystone.server.flask.application raise exception.TokenNotFound(_('Failed to validate token')) ERROR keystone.server.flask.application keystone.exception.TokenNotFound: Failed to validate token [2] $ grep f47b3827 */*log nova/nova-api.log: INFO nova.api.openstack.requestlog [None req-f47b3827-9070-4761-a9de-0f8c854ccc93 1f24a1c85bb24bc3aa83a22bc6b9a47e 2f764cefd79544f1959b3743281b072d - - 16cb1fce3b1b4842b3be2fb4e88c5c69 16cb1fce3b1b4842b3be2fb4e88c5c69] 10.70.142.1 "GET /v2.1/servers/72970654-cbaf-4e0e-94e0-70e7ba3e0db4" status: 200 len: 3747 microversion: 2.1 time: 0.104714 nova/nova-api.log: WARNING keystonemiddleware.auth_token [None req-f47b3827-9070-4761-a9de-0f8c854ccc93 1f24a1c85bb24bc3aa83a22bc6b9a47e 2f764cefd79544f1959b3743281b072d - - 16cb1fce3b1b4842b3be2fb4e88c5c69 16cb1fce3b1b4842b3be2fb4e88c5c69] Authorization failed for token: keystonemiddleware.auth_token._exceptions.InvalidToken: Token authorization failed nova/nova-api.log: INFO nova.api.openstack.requestlog [None req-f47b3827-9070-4761-a9de-0f8c854ccc93 1f24a1c85bb24bc3aa83a22bc6b9a47e 2f764cefd79544f1959b3743281b072d - - 16cb1fce3b1b4842b3be2fb4e88c5c69 16cb1fce3b1b4842b3be2fb4e88c5c69] 10.70.142.1 "GET /v2.1/servers/detail?name=shoot--system--mon" status: 401 len: 114 microversion: - time: 0.078451

2 3

[release] Release countdown for week R-5
by Thierry Carrez 22 Aug '25

22 Aug '25

Development Focus ----------------- We are getting close to the end of the 2025.2 "Flamingo" cycle! Next week on August 28th, 2025 is the Flamingo-3 milestone, also known as feature freeze. It's time to wrap up feature work in the services and their client libraries, and defer features that won't make it to the 2026.1 "Gazpacho" cycle. General Information ------------------- This coming week is the deadline for client libraries: their last feature release needs to happen before "Client library freeze" on August 28th, 2025. Only bugfix releases will be allowed beyond this point. When requesting those library releases, you can also include the stable/2025.2 branching request with the review. As an example, see the "branches" section here: https://opendev.org/openstack/releases/src/branch/master/deliverables/pike/… August 28th, 2025 is also the deadline for feature work in all OpenStack deliverables following the cycle-with-rc model. To help those projects produce a first release candidate in time, only bugfixes should be allowed in the master branch beyond this point. Any feature work past that deadline has to be raised as a Feature Freeze Exception (FFE) and approved by the team PTL. Finally, feature freeze is also a good time for submitting a first version of your cycle-highlights. Cycle highlights are the raw data that helps shape what is communicated in press releases and other release activity at the end of the cycle, avoiding direct contacts from marketing folks. See https://docs.openstack.org/project-team-guide/release-management.html#cycle… for more details. Upcoming Deadlines & Dates -------------------------- Flamingo-3 milestone (feature freeze): August 28th, 2025 (R-5 week) RC1 deadline: September 12th, 2025 (R-3 week) Final RC deadline: September 25th, 2025 (R-1 week) 2025.2 "Flamingo" final release: October 1st, 2025 OpenInfra Summit Europe: October 17th-19th, 2025 -- Thierry Carrez (ttx)

1 0

[blazar] Blazar-dashboard contains non-free files (ie: minified Javascripts)
by Thomas Goirand 22 Aug '25

22 Aug '25

Hi, I've been trying to package Blazar, all is already in Debian, but I can't get blazar-dashboard in, because upstream source contains non-free files. Namely: https://github.com/openstack/blazar-dashboard/blob/master/blazar_dashboard/… is a minifed version of a much more complex package: https://github.com/apexcharts/apexcharts.js/tree/v3.31.0 Reminder: minified Javascripts are considered by most distributions (this includes Red Hat, Ubuntu, and in my case Debian) as non-free files that cannot be shipped in the distribution without the underlying source code, and packages must build from the not minified version. Could the Blazar team work on un-vendoring apexcharts.min.js, possibly removing it completely, or replacing it with a source-full version? Cheers, Thomas Goirand (zigo)

4 6

[neutron] Drivers meeting canceled Friday, August 22nd
by Brian Haley 21 Aug '25

21 Aug '25

Hello Neutrinos: I am going to cancel tomorrow's Drivers meetings as there will not be quorum. Just a reminder there are still open specs that need updates and/or review, list is at [0]. Have a nice weekend! -Brian [0] https://review.opendev.org/q/status:open+project:openstack/neutron-specs

1 0

[all] Keeping old unmaintained branches open for longer time, but with no CI, instead of EOL tags
by Thomas Goirand 21 Aug '25

21 Aug '25

Hi, It's our policy that we maintain only a few branches, currently, from Caracal to Epoxy (so, 3 stable branches). Currently, when a Stable branch becomes unsuported, we rename that branch as: unmaintained/2023.1 which is fine, as we can still commit there. Though after some times, the branches are deleted, and instead, we just do a tag such as: zed-EOL Jeremy Stanley just wrote to me on IRC: "workflows, processes and policies are built around many years of an assumption that unused branches will be deleted" Keeping unmaintained branches "has put a lot of additional strain on project maintainers and our systems" (still quoting Jeremy). Though each time there's a new (grave?) security problem, this topic comes back, as we still have no solution for these cases. As a downstream, I still need to write backports for these important patches, sometimes long after the branches are EOL. Red Hat too... While I agree with all what Jeremy told me on IRC, and I don't think we should attempt to maintain the CI for too long (as this takes too much of our time), I still believe we should keep a way to share patches. Downstream (like myself for Debian) run their own CI based on packages, and it's always better if we can share patches. It doesn't have to be with a maintained CI. Just having opened branches would be enough. Your thoughts? Cheers, Thomas Goirand (zigo)

6 6

[all][elections][ptl][tc] Combined PTL/TC 2026.1 cycle Election Nominations End
by Ian Y. Choi 20 Aug '25

20 Aug '25

The PTL and TC Nomination period is now over. The official candidate lists for PTLs [0] and TC seats [1] are available on the election website. -- PTL Election Details -- There are 4 projects without candidates, so according to this resolution[2], the TC will have to decide how the following projects will proceed: Monasca, OpenStack_Charms, Venus, Vitrage There are 1 project that will have elections: Horizon. -- TC Election Details -- The official candidate list is available on the election website[1]. Now begins the campaigning period where candidates and electorate may debate their statements. Polling will start Aug 27, 2025 23:45 UTC. Thank you, [0] https://governance.openstack.org/election/#ptl-candidates [1] https://governance.openstack.org/election/#tc-candidates [2] https://governance.openstack.org/resolutions/20141128-elections-process-for…

1 0

OSSN-0094: Ensuring Volume Safety with Nova and Watcher
by Jay Faulkner 20 Aug '25

20 Aug '25

OSSN-0094: Ensuring Volume Safety with Nova and Watcher == Summary == A vulnerability has been identified in OpenStack Nova and OpenStack Watcher in conjunction with volume swap operations performed by the Watcher service. Under specific circumstances, this can lead to a situation where two Nova libvirt instances could reference the same block device, allowing accidental information disclosure to the unauthorized instance. == Affected Services / Software == Services: Nova,Watcher Releases: all supported releases == Discussion == The issue occurs when Watcher's zone migration strategy performs the following sequence of events: 1. Watcher initiates a volume swap using Nova's internal-only volume swap API 2. Watcher initiates a live migration of the same instance 3. In some error cases connection details may have failed to update storage references. These invalid details are used during the live migration. === Required Access === The swap volume, live migration and all Watcher APIs are admin only so with default policy is only possible to create the inconsistent state described in this OSSN if you have admin rights on the relevant OpenStack project. === Further Watcher Hardening === The Watcher service, when first created, often implemented its own means to perform operations. Many of those operations can now be done natively via other OpenStack services. In the specific context of OSSN-0094, the ability to migrate Cinder volumes between storage backends is such an example. Additionally, the Cinder volume migration in Watcher created a new Keystone user with the admin role assigned for the instance owners' project and then used that user to perform API requests on behalf of the project. This code has been removed. Finally, due to limited error handling and no validation that the objects involved were migrated properly, some error scenarios could have led to a source volume being deleted despite not having been migrated properly. === Resolution === Nova will now reject any request to swap a volume that has an empty migration status, effectively restricting the usage of this API to Cinder. This brings the API validation in line with the documentation. Watchers internal implementation of swap volume has been deleted and updated to use Cinder's native volume migration as a replacement. Watcher no longer creates temporary Keystone users in normal operation. === Patches === Patches for Nova and Watcher have been backported to all supported stable branches and committed to master branch. stable/2025.1: * Watcher: https://review.opendev.org/c/openstack/watcher/+/957770 * Nova: https://review.opendev.org/c/openstack/nova/+/957759 stable/2024.2: * Watcher: https://review.opendev.org/c/openstack/watcher/+/957773 * Nova: https://review.opendev.org/c/openstack/nova/+/957762 stable/2024.1: * Watcher: https://review.opendev.org/c/openstack/watcher/+/957774 * Nova: https://review.opendev.org/c/openstack/nova/+/957764 == Recommended Actions == * Operators using Watcher's zone migration strategy should apply the provided Watcher and Nova patches as soon as possible. * Operators should refrain from using the swap volume migration action in Watcher. The compatibility code for swap volume that uses a Cinder-based migration may be removed in a future API version. * Operators should audit all users with the admin role and ensure no temporary Watcher-created users remain. * Operators using custom policy for volume attachment (''/servers/{server_id}/os-volume_attachments/{volume_id}'') or live migration API should review the state of existing instances which have had volume migrations. Any instance in an inconsistent state can be resolved by hard rebooting the instance using Nova's API. == Contacts / References == * Author: Sean Mooney <smooney(a)redhat.com>, Jay Faulkner <jay(a)jvf.cc> * This OSSN : https://wiki.openstack.org/wiki/OSSN/OSSN-0094 * Original LaunchPad Bug : https://bugs.launchpad.net/nova/+bug/2112187 * Mailing List : [Security] tag on openstack-discuss(a)lists.openstack.org * OpenStack Security Project : https://launchpad.net/~openstack-ossg * CVE: None

1 0

[vitrage][tc] Project status
by Takashi Kajinami 20 Aug '25

20 Aug '25

Hi, Some of you might be aware of this, but tempest jobs in vitrage repo have been broken for some time (I remember I saw consistent failures early in this cycle and I'm afraid that the situation hasn't been improved.) I spent some time to dig into these failures and found out a few problems. However I'm afraid I can't fix these all with my limited knowledge about vitrage. # I've helped its project maintenance for some time but I've never looked into # its implementations quite in detail. So I'm sharing my observations here hoping someone who know better about it can look into these. 1. Usage of removed oslo_context.context.RequestContext interfaces This is the most trivial and can be fixed easily. https://review.opendev.org/c/openstack/vitrage/+/957004/2/vitrage/api/hooks… 2. Usage of asyncore modules from pysnmp-lextudio Recent release of pysnmp-lextudio no longer provides these modules, likely due to removal of asyncore in Python 3.12 . I was drafting the migration to asyncio version in https://review.opendev.org/c/openstack/vitrage/+/957004 but learned simple replacement does not work and we need more careful assessment. This might be the most tricky problem atm. 3. Some tempest test failures I can no longer see old CI results, but as far as I'm aware, CI jobs were blocked by a few tests consistently failing early in this cycle so we may have to dig into these, too. You may find some tempest tests failures in https://review.opendev.org/c/openstack/vitrage/+/957004 though I'm unsure if these are related to broken snmp service, which is caused by incomplete migration to asyncio (which I described in 2). I'm adding the tc tag, to notify them of the current status. Thank you, Takashi Kajinami -- Takashi Kajinami irc: tkajinam github: https://github.com/kajinamit launchpad: https://launchpad.net/~kajinamit

2 2

[swift] Unmaintained branch cleanup
by Tim Burke 20 Aug '25

20 Aug '25

Swift currently has six unmaintained branches: - unmaintained/2023.1 - unmaintained/zed - unmaintained/yoga - unmaintained/xena - unmaintained/wallaby - unmaintained/victoria Half of them have not been updated this year. For all of them, the only patches since the transition to unmaintained status were to try to maintain CI. While two of them have open patches, they all seem to revolve around maintaining CI and none of them currently pass. I propose transitioning all of these to end-of-life. If you have any objections, please respond here on the mailing list or at https://review.opendev.org/c/openstack/releases/+/958101 which makes the change. Tim

1 0

[horizon] Today's weekly meeting is cancelled
by Tatiana Ovchinnikova 20 Aug '25

20 Aug '25

Hello team, A reminder that today's meeting is cancelled since more than a half of the team is busy with downstream activities. With kind regards, Tatiana

1 0

[masakari] Add a rpc api for ping check
by do-gyun kim 19 Aug '25

19 Aug '25

Similar to Nova, I think it would be good to add ping api to masakari engine for rpc health check. This can be used for reading business and lifestyle check in Masakari distributed to Kubernetes through OpenStack Helm. Currently, there is no health check for masakari-engine in openstack-helm project, but it would be good to add it. Blueprint: https://blueprints.launchpad.net/masakari/+spec/add-a-rpc-api-for-ping

1 1