July 2025 - openstack-discuss - lists.openstack.org

Short Bitergia dashboard outage due to maintenance
by Ildiko Vancsa 16 Jul '25

16 Jul '25

Hi OpenStack community, I’m reaching out to let you know that the OpenStack Bitergia metrics dashboard[1] will be unavailable for a short period of time due to scheduled maintenance, where the underlying OpenSearch cluster will be updated. Details of the downtime: * Start Date: Thursday, July 17th at 10:00 AM CEST (01:00 AM PDT) * End Date: Thursday, July 17th at 12:00 PM CEST (03:00 AM PDT) __During this maintenance window, the dashboard will be inaccessible.__ Thank you for your understanding. Best Regards, Ildikó [1] https://openstack.biterg.io/app/dashboards#/view/Overview

1 0

[publiccloud-sig] Next meeting of Public Cloud SIG - July 16th (tomorrow) at 0700 UTC
by Felix Kronlage-Dammers 15 Jul '25

15 Jul '25

Hi everyone, This upcoming Wednesday (which is tomorrow, July 16th) the next meeting of the publiccloud-sig is going to happen. We’ll be meeting at 0700 UTC here: https://meetpad.opendev.org/publiccloud-sig See also here for all other details: https://wiki.openstack.org/wiki/PublicCloudSIG Have fun! cheers felix -- Felix Kronlage-Dammers Open Source Business Alliance - Bundesverband für digitale Souveränität e.V. Tel.: +49-30-206539-205 | Matrix: @fkronlage:matrix.org | fkr(a)osb-alliance.com

1 0

[nova] Information Sharing for Arm CCA Feature (Following 4/8 PTG)
by taketani.ryo＠fujitsu.com 14 Jul '25

14 Jul '25

Thank you for the productive discussion about Arm CCA feature [1] at the PTG on April 8th. > The use case for Arm CCA looks ok. But it is a bit early. It is wise to wait at least libvirt / qemu release to have a "stable" code. > We may want to have a OS distribution version (such as Ubuntu XX.YY) which supports Arm CCA so that users can actually use/test the feature The above information is quoted from the PTG Etherpad [2](L316) summary. I'd like to follow up on these points. I'd like to share relevant information about Arm CCA surrounding components (libvirt, QEMU, OS Distributions(e.g., Ubuntu xx.xx), hardware) as it becomes available, and proceed with the discussion step by step.. I'm starting with this email, but if there's a more appropriate method for sharing this type of information, please let me know. Here's the Arm CCA software components information I can share at this time: * Linux Kernel: The roadmap is outlined on the fifth page of the third attachment in this link [3]. The initial commits I've proposed to OpenStack are focused on RMM 1.0. KVM host support for RMM 1.0 will be available in H2 2025. * QEMU Upstream Status: The development is in-progress, awaiting the Linux Kernel merge * libvirt Upstream Status: The development is in-progress, awaiting the QEMU merge * OS Distribution Support: The road map is not clear now > We may want to have a OS distribution version (such as Ubuntu XX.YY) which supports Arm CCA so that users can actually use/test the feature I have a question regarding the above. For design discussions leading to spec approval, I understand that upstream QEMU/libvirt stable release is necessary. Is a specific OS distribution release (e.g., Ubuntu xx.xx) also required for spec approval? [1] https://review.opendev.org/c/openstack/nova-specs/+/938276 [2] https://etherpad.opendev.org/p/nova-2025.2-ptg [3] https://lists.trustedfirmware.org/archives/list/tsc@lists.trustedfirmware.o… Regards, Ryo Taketani

3 11

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

14 Jul '25

Hello Stackers, We're eleven weeks away from the date of the coordinated release of OpenStack 2025.2 ("Flamingo") [1]. The feature freeze date for this release cycle is 2025-08-28. OpenStack project teams are busy working on and polishing features to meet this deadline. In the past week, we marked the shade and os-client-config packages as deprecated [2]. The functionality provided by these two packages has long been available through openstacksdk. We don't plan to create any new releases for these packages unless critical bugs are discovered. Besides that, there have been no significant governance updates; however, several proposals are under community review. As part of the OpenInfra Foundation's transition under the Linux Foundation, your individual membership must be renewed. The OIF staff have made this a super-easy one-click process [3]. Please complete this by 2025-07-19 to contest or vote in the next OIF Board elections. OpenStack's own PTL and TC elections will occur between 23:45 UTC on 2025-08-27 and 23:45 UTC on 2025-09-17 [4]. To contest or vote in these elections, you must renew your Foundation membership by 00:00 UTC on 2025-08-20. Don't wait—this process only takes a couple of minutes! === Weekly Meeting === The last weekly IRC meeting of the OpenStack TC took place on 2025-07-08 [5]. We noted that consensus is emerging on the updated Eventlet removal timelines [6]. We followed up on the removal of all references to the Contributor License Agreement from governance docs and OpenStack manuals. There may still be some references lurking in various project documentation websites. We request contributors to file bugs or submit simple documentation updates to switch these references to the Developer Certificate of Origin [7]. OpenStack CI jobs saw some multinode hiccups over the week due to bugs in zuul-launcher. These have been resolved by the OpenDev Infra team, and CentOS/Rocky 10 along with Debian Trixie node images are expected to be served by zuul-launcher soon. The proposal to retire Monasca [8] was discussed at length. While the project has been inactive for several cycles, the TC agreed to give maintainers a chance to state their intentions before moving ahead with retirement. We also agreed that we need better visibility into inactive projects for users and operators. We'll be tweaking the appropriate badges that show up on the repositories and adding notices on project documentation websites. Lastly, we were updated that work is underway to fully remove CLA references from Gerrit. The next weekly meeting of the OpenStack TC is on 2025-07-15 at 17:00 UTC. This meeting will be hosted over IRC in OFTC's #openstack-tc channel. Please find the meeting details, including the agenda, on the meeting's wiki page [9]. I hope you'll be able to join us. === Governance Proposals === ==== Merged ==== - Deprecate shade, os-client-config | https://review.opendev.org/c/openstack/governance/+/953549 ==== Open for review ==== - Remove Monasca from active project | https://review.opendev.org/c/openstack/governance/+/953671 - Make Eventlet removal deadlines more acceptable for operators | https://review.opendev.org/c/openstack/governance/+/952903 - Require declaration of affiliation from TC Candidates | https://review.opendev.org/c/openstack/governance/+/949432 - os-test-images never releases | https://review.opendev.org/c/openstack/governance/+/954249 === Upcoming Events === - 2025-07-19: OpenInfra Days, Indonesia: https://2025.openinfra.id/ - 2025-07-26: OpenInfra Days, Vietnam: https://www.vietopeninfra.org/void2025 - 2025-08-06: Nominations open for OpenStack elections: https://governance.openstack.org/election/ === 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 17:00 UTC [9]. 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] Deprecation of shade and os-client-config: https://review.opendev.org/c/openstack/governance/+/953549 [3] Renew OIF membership: https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack… [4] OpenStack Election Schedule: https://summit2025.openinfra.org/a/schedule [5] TC Meeting IRC Log 2025-07-08: https://meetings.opendev.org/meetings/tc/2025/tc.2025-07-08-17.00.html [6] Eventlet removal timeline proposal: https://review.opendev.org/c/openstack/governance/+/952903 [7] DCO instructions: https://docs.openstack.org/contributors/common/dco.html [8] Retiring monasca: https://review.opendev.org/c/openstack/governance/+/953671 [9] TC Meeting Agenda, 2025-07-15: https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Next_Meeting

1 0

Handling VirtualMedia under Systems path (HPE Superdome Redfish)
by Sangle, Pooja 14 Jul '25

14 Jul '25

Hi all, I'm working with HPE Superdome hardware and noticed that their Redfish implementation exposes VirtualMedia under `/redfish/v1/Systems/{id}/VirtualMedia/`, which differs from the common `/Managers/{id}/VirtualMedia/` path expected by sushy and Ironic. HPE confirms this is standard-compliant per Redfish, but Ironic fails to locate the media devices due to this layout. Before opening a bug or patch, is there known support or discussion around handling this variant? Any pointers welcome! Best, Pooja Sangle

3 4

[neutron] Bug report Jul 7 - Jul 13
by Rodolfo Alonso Hernandez 14 Jul '25

14 Jul '25

Hello Neutrinos: This is the bug report for week 28 (Jul 7 - Jul 13). High: * master networking sfc jobs broken as ovs agent crashing ( https://bugs.launchpad.net/neutron/+bug/2116337) Project: networking-sfc. Assigned. Patches: https://review.opendev.org/c/openstack/releases/+/954702 , https://review.opendev.org/c/openstack/networking-sfc/+/954633 Medium: * remote-managed vnic-type binding profile validation error ( https://bugs.launchpad.net/neutron/+bug/2116087) Assigned. Patch: https://review.opendev.org/c/openstack/neutron/+/954292 * OVN network metadata is broken if allowed-address is configured using the same IP (https://bugs.launchpad.net/neutron/+bug/2116249) Assigned. Patch: https://review.opendev.org/c/openstack/neutron/+/954570 Low: * [Doc][OVN] Precedence of enforcement for QoS resource types in ML2/OVN ( https://bugs.launchpad.net/neutron/+bug/2116317) Assigned. Patch: https://review.opendev.org/c/openstack/neutron/+/954911 Incomplete * gateway_port: of NAT configured on logical router: is not a valid distributed gateway port on that router ( https://bugs.launchpad.net/neutron/+bug/2116335) Missing logs. * VPN Perfect Forward Secrecy (PFS) is deactivated although configured as active (https://bugs.launchpad.net/neutron/+bug/2116723) Missing version, reproducer, logs. Regards.

1 0

[neutron] Disable subnet-external-network extension
by Maximilian Stinsky-Damke 11 Jul '25

11 Jul '25

Greetings, Since Neutron 2024.2 (25.0.0), the subnet-external-network extension is loaded by default. This causes subnetworks that are part of external networks to be visible to non-admin users. We found this behavior a bit confusing for regular users, as those subnetworks are often not usable for spawning VMs or creating load balancers. Depending on the number of external subnetworks, dashboards like Networks and Load Balancer Create in Octavia can become cluttered with entries that are effectively unusable for non-admins, as they are intended only for routers and floating IPs. I’ve reviewed the patches mentioned in [1], and as far as I can tell, the new extension is enabled by default with no apparent way to disable it or revert to the previous behavior. Am I missing something? Is there a way to prevent external subnetworks from being shown to non-admin users? [1] https://bugs.launchpad.net/neutron/+bug/2051831 Thanks in advance, Best regards, Max

2 2

[neutron] Drivers meeting canceled Friday, July 11th
by Brian Haley 10 Jul '25

10 Jul '25

Hello Neutrinos: I'm going to cancel tomorrow's drivers meeting as there is currently nothing listed in the agenda. Just a reminder there are still open specs that need review, list is at [0]. Have a nice weekend! -Brian [0] https://review.opendev.org/q/status:open+project:openstack/neutron-specs

1 0

[skyline] Request to extend core reviewers team
by Vladimir Kozhukalov 09 Jul '25

09 Jul '25

Hi team, The Skyline project seems to be interesting for many users but the review is slow at the moment. Maybe we could call for more volunteers who are able to spend some of their time for review and extend the project core reviewers team. Opinions are welcome. -- Best regards, Kozhukalov Vladimir

3 2

[neutron] Seeking Advise: Automatic Assignment of Default Neutron QoS Policy in OVN-based OpenStack
by Simon Stephan 09 Jul '25

09 Jul '25

Hi all, we’re currently migrating an OpenStack deployment from a setup using libvirt-based QoS (with per-flavor bandwidth limits) to a newer environment using OVN as the networking backend. In the previous environment, bandwidth limits were enforced via libvirt, and each flavor had an associated QoS configuration. Now with OVN, this approach is no longer viable, and we are evaluating Neutron’s native QoS feature as a replacement. Our goals: * Enforce one default bandwidth limit per project (formerly done via flavor). * Apply a default QoS policy automatically to every new project, without requiring manual intervention. * Allow users to create their own projects via Domain Manager. Current Observations: * Neutron QoS policies must be explicitly associated with ports or networks, and there is no system-wide default or setting it on a domain level * There is no built-in mechanism in Neutron or Keystone to automatically attach a default QoS policy when a new project is created. Our Proposed Solution: We are exploring a solution where we: 1. Listen to project.create events on the RabbitMQ message bus. 2. Automatically assign a shared default QoS policy (defined in our service project and marked as shared=True) to the newly created project. 3. Possibly enforce this via automation, e.g. an event-driven microservice or script that uses openstacksdk. Question to the community: * Has anyone implemented something similar? * Is there an existing feature or plugin to apply a default Neutron QoS policy to all newly created projects or their ports/networks? * Are there better alternatives or architectural considerations we should keep in mind? * Any feedback or suggestions would be greatly appreciated. Regards, Simon

2 1