September 2025 - openstack-discuss

[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 6

[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 03 Sep '25

03 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 02 Sep '25

02 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