May 2025 - openstack-discuss - lists.openstack.org

[ops][upgrades][slurp] Seeking OpenStack Upgrade Case Studies
by Allison Price 08 May '25

08 May '25

Hi everyone, We have now published two case studies from OpenStack users who have implemented and are benefiting from the SLURP upgrade process[1]: Cleura[2] and Indiana University[3] I wanted to follow up to see if there are other organizations who have implemented the SLURP upgrade process who would like to tell your story? If we can get a few more, I would love to schedule an OpenInfra Live to deep dive into the improvements made around OpenStack upgrades and what users stuck on older releases should know. If you are interested, please let me know. And even if you’re not but you’re still using OpenStack—please remember to take the OpenStack User Survey[4] so we can learn more! Thanks! Allison [1] https://docs.openstack.org/project-team-guide/release-cadence-adjustment.ht… [2]https://superuser.openinfra.org/articles/streamlining-openstack-upgrades-… [3] https://superuser.openinfra.org/articles/streamlining-openstack-upgrades-a-… [4] https://www.openstack.org/user-survey

3 10

[skyline-console] Default project
by Michael Knox 08 May '25

08 May '25

Hey folks, I don't seem to see how Skyline-console uses a "default" project. We are use Skyline in our lab, across multiple projects, but when I log in, I always land in "admin" The link to change project works fine, but the "Default" link just brings up the same modal, nothing seems to be session stored if I set knox to be my default. Is there something I am missing or is this a "to be implemented" thing? [image: CleanShot 2025-05-08 at 14.43.30(a)2x.png] Cheers Michael

2 2

[tc][ops][deployment] Bulk removal of wsgi scripts
by Stephen Finucane 08 May '25

08 May '25

o/ As I noted nearly 18 months ago [1], changes in the Python packaging ecosystem are forcing our hand with regards to the necessity of to both add 'pyproject.toml' files and remove support for pbr's 'wsgi_scripts' entrypoint feature. I was out last week and the week prior, but it seems there's been been a burst of activity around both areas owning to some setuptools issues. This is great to see, and the latter in particular will finally fulfil a community goal that was approved over a year ago [2]. Unfortunately, as a result of the delay in service projects addressing this goal, it seems likely (IMO) that we're not going to be able to wait two release cycles (until H, for projects only adding these modules now in F) to drop the wsgi scripts. This is because the setuptools maintainers understandably have little interest in maintaining the easy_install APIs that we had been relying on to date as public APIs, which means it's very likely that this feature will break in pbr sooner rather than later. This being the case, I'd like to suggest that we rip the band aid off, and proceed with both adding new '$service.wsgi' modules and removing the old '$service-wsgi' scripts in the *same release*. To some degree, this ship has already sailed and at least Designate and Octavia have already done this [3][4] (and others like Magnum are planning to do so [5]) but I'd like to at least let deployment tooling folks know that this will be happening en masse. (It would also be nice to be able to plough on and close this effort off in the likes of Nova and Placement, rather than waiting as Sean Mooney is suggesting [6][7] :).) Please let me know if anyone has any concerns. If not, I'll take silence as tacit agreement and (a) keep pursuing this approach in other services that are currently broken (like Masakari [8]) and (b) poke Sean with increasingly sharp sticks until they approve those Nova and Placement patches. Cheers, Stephen [1] https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack… [2] https://review.opendev.org/c/openstack/governance/+/902807 [3] https://review.opendev.org/c/openstack/designate/+/902846 [4] https://review.opendev.org/c/openstack/octavia/+/902812 [5] https://review.opendev.org/c/openstack/magnum/+/949110 [6] https://review.opendev.org/c/openstack/nova/+/902688 [7] https://review.opendev.org/c/openstack/placement/+/919582 [8] https://review.opendev.org/c/openstack/masakari/+/949154

5 7

[OSSA-2025-001] Ironic fails to restrict paths used for file:// image URLs (CVE-2025-44021)
by Jay Faulkner 08 May '25

08 May '25

========================================================================= OSSA-2025-001: Ironic fails to restrict paths used forfile:// image URLs ========================================================================= :Date: May 08, 2024 :CVE: CVE-2025-44021 Affects ~~~~~~~ - Ironic: <24.1.3, >=25.0.0 <26.1.1, >=27.0.0, <29.0.1 Description ~~~~~~~~~~~ Julia Kreger of Red Hat noticed a vulnerability in image handling for Ironic. A malicious project assigned as a node owner can provide a path to any local file readable by the ironic-conductor which may then be written to the target node disk. This is only possible via deployments performed directly via Ironic's API and cannot be triggered via Nova's virt driver. This is difficult to exploit in practice, as a node deployed in this manner should not ever reach ACTIVE state, but it still represents a danger in environments running with non-default, insecure configurations such as with automated cleaning disabled. Patches ~~~~~~~ -https://review.opendev.org/c/openstack/ironic/+/949175 (2024.1/caracal) -https://review.opendev.org/c/openstack/ironic/+/949174 (2024.2/dalmatian) -https://review.opendev.org/c/openstack/ironic/+/949173 (2025.1/epoxy) - Patch attached tohttps://bugs.launchpad.net/ironic/+bug/2107847/comments/47 (Bobcat/2023.2-eol) -https://review.opendev.org/c/openstack/ironic/+/949186 (Bugfix/26.0) -https://review.opendev.org/c/openstack/ironic/+/949185 (Bugfix/27.0) -https://review.opendev.org/c/openstack/ironic/+/949184 (Bugfix/28.0) -https://review.opendev.org/c/openstack/ironic/+/949172 (Master) -https://review.opendev.org/c/openstack/ironic/+/949182 (Unmaintained/2023.1 antelope) -https://review.opendev.org/c/openstack/ironic/+/949179 (Unmaintained/xena) -https://review.opendev.org/c/openstack/ironic/+/949177 (Unmaintained/yoga) -https://review.opendev.org/c/openstack/ironic/+/949176 (Unmaintained/zed) Credits ~~~~~~~ - Julia Kreger from Red Hat (CVE-2025-44021) References ~~~~~~~~~~ -https://launchpad.net/bugs/2107847 -http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2025-44021 Notes ~~~~~ - Patches have been provided for all supported Ironic branches. As a courtesy, we have also provided patches for some unmaintained branches and the recently end-of-life 2023.2/bobcat release. As usual, we will provide updated releases off maintained branches, but will not create new releases off bugfix or unmaintained branches.

1 0

[Glance] Cancelling 2025-05-08 meeting
by Cyril Roelandt 07 May '25

07 May '25

Hello, Tomorrow's meeting is cancelled because we will not have enough members around due to a bank holiday. Cyril Roelandt

1 0

[kolla] Post Flamingo/2025.2 recap during 21st May weekly meeting
by Michał Nasiadka 07 May '25

07 May '25

Hello, As decided during the last PTG - we're going to have post-PTG recap during 21st May 2025 weekly meeting. We're going to extend it to 2 hours - so 13:00 to 15:00 UTC. Meetpad URL: https://meetpad.opendev.org/kolla-flamingo-ptg See you there! -- Michał Nasiadka mnasiadka(a)gmail.com

1 0

[cinder] Weekly meeting canceled today
by Jon Bernard 07 May '25

07 May '25

Hello all, Metallica is playing this afternoon and my entire town is shutting down today, including schools and childcare, so lets meet next week ;) Take care, -- Jon

1 0

[Wallaby] Interface operations not supported for ovn_metadata_agent
by davorin.mikulic＠gmail.com 07 May '25

07 May '25

Dear openstack community, I am trying to get metadata service to work on a TripleO Wallaby Openstack. Upon successful creation of the virtual machine in a geneve type internal network, namespace gets created on the compute node which hosts the VM: [root@overcloud-computesriov-0 ~]# ip netns list ovnmeta-fae7b699-3086-4213-bec7-9d91737c934c (id: 0) [root@overcloud-computesriov-0 ~]# ip netns exec ovnmeta-fae7b699-3086-4213-bec7-9d91737c934c ip a s 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: tapfae7b699-31@if34: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000 link/ether fa:16:3e:d0:d6:01 brd ff:ff:ff:ff:ff:ff link-netnsid 0 inet6 fe80::ac69:a2ff:feb3:89c9/64 scope link valid_lft forever preferred_lft forever The problem is that the VM cannot reach the metadata service IP 169.254.169.254 even though it has the route to it via 10.0.0.2 (DHCP port in the internal network). I can also see ovn_metadata_agent crashing every 6 seconds with the following: 2025-05-05 13:22:39.044 226779 INFO neutron.common.config [-] Logging enabled! 2025-05-05 13:22:39.044 226779 INFO neutron.common.config [-] /usr/bin/networking-ovn-metadata-agent version 18.6.1.dev209 2025-05-05 13:22:39.050 226779 WARNING oslo_config.cfg [-] Deprecated: Option "heartbeat_in_pthread" from group "oslo_messaging_rabbit" is deprecated for removal. Its value may be silently ignored in the future. 2025-05-05 13:22:39.064 226779 INFO ovsdbapp.backend.ovs_idl.vlog [-] tcp:127.0.0.1:6640: connecting... 2025-05-05 13:22:39.064 226779 INFO ovsdbapp.backend.ovs_idl.vlog [-] tcp:127.0.0.1:6640: connected 2025-05-05 13:22:39.095 226779 INFO neutron.agent.ovn.metadata.agent [-] Loaded chassis name 983d11af-8faf-4f85-99c2-62c00ed8165b (UUID: 983d11af-8faf-4f85-99c2-62c00ed8165b) and ovn bridge br-int. 2025-05-05 13:22:39.108 226779 INFO neutron.agent.ovn.metadata.ovsdb [-] Getting OvsdbSbOvnIdl for MetadataAgent with retry 2025-05-05 13:22:39.108 226779 INFO ovsdbapp.backend.ovs_idl.vlog [-] tcp:10.100.22.91:6642: connecting... 2025-05-05 13:22:39.109 226779 INFO ovsdbapp.backend.ovs_idl.vlog [-] tcp:10.100.22.91:6642: connected 2025-05-05 13:22:39.126 226779 INFO oslo_service.service [-] Starting 2 workers 2025-05-05 13:22:39.136 226779 INFO oslo.privsep.daemon [-] Running privsep helper: ['sudo', 'neutron-rootwrap', '/etc/neutron/rootwrap.conf', 'privsep-helper', '--config-file', '/etc/neutron/neutron.conf', '--config-file', '/etc/neutron/plugins/networking-ovn/networking-ovn-metadata-agent.ini', '--privsep_context', 'neutron.privileged.default', '--privsep_sock_path', '/tmp/tmpnbw1fxbg/privsep.sock'] 2025-05-05 13:22:39.171 226809 INFO neutron.agent.ovn.metadata.ovsdb [-] Getting OvsdbSbOvnIdl for MetadataAgent with retry 2025-05-05 13:22:39.173 226809 INFO ovsdbapp.backend.ovs_idl.vlog [-] tcp:10.100.22.95:6642: connecting... 2025-05-05 13:22:39.174 226810 INFO neutron.agent.ovn.metadata.ovsdb [-] Getting OvsdbSbOvnIdl for MetadataAgent with retry 2025-05-05 13:22:39.175 226809 INFO ovsdbapp.backend.ovs_idl.vlog [-] tcp:10.100.22.95:6642: connected 2025-05-05 13:22:39.176 226810 INFO ovsdbapp.backend.ovs_idl.vlog [-] tcp:10.100.22.67:6642: connecting... 2025-05-05 13:22:39.178 226810 INFO ovsdbapp.backend.ovs_idl.vlog [-] tcp:10.100.22.67:6642: connected 2025-05-05 13:22:39.204 226809 INFO eventlet.wsgi.server [-] (226809) wsgi starting up on http:/var/lib/neutron/metadata_proxy 2025-05-05 13:22:39.209 226810 INFO eventlet.wsgi.server [-] (226810) wsgi starting up on http:/var/lib/neutron/metadata_proxy 2025-05-05 13:22:40.270 226779 INFO oslo.privsep.daemon [-] Spawned new privsep daemon via rootwrap 2025-05-05 13:22:40.167 226859 INFO oslo.privsep.daemon [-] privsep daemon starting 2025-05-05 13:22:40.175 226859 INFO oslo.privsep.daemon [-] privsep process running with uid/gid: 0/0 2025-05-05 13:22:40.180 226859 INFO oslo.privsep.daemon [-] privsep process running with capabilities (eff/prm/inh): CAP_DAC_OVERRIDE|CAP_DAC_READ_SEARCH|CAP_NET_ADMIN|CAP_SYS_ADMIN/CAP_DAC_OVERRIDE|CAP_DAC_READ_SEARCH|CAP_NET_ADMIN|CAP_SYS_ADMIN/none 2025-05-05 13:22:40.180 226859 INFO oslo.privsep.daemon [-] privsep daemon running as pid 226859 2025-05-05 13:22:40.972 226779 INFO neutron.agent.ovn.metadata.agent [-] Provisioning metadata for network fae7b699-3086-4213-bec7-9d91737c934c 2025-05-05 13:22:41.159 226779 CRITICAL neutron [-] Unhandled error: neutron.privileged.agent.linux.ip_lib.InterfaceOperationNotSupported: Operation not supported on interface tapfae7b699-31, namespace ovnmeta-fae7b699-3086-4213-bec7-9d91737c934c. 2025-05-05 13:22:41.159 226779 ERROR neutron Traceback (most recent call last): 2025-05-05 13:22:41.159 226779 ERROR neutron File "/usr/bin/networking-ovn-metadata-agent", line 10, in <module> 2025-05-05 13:22:41.159 226779 ERROR neutron sys.exit(main()) 2025-05-05 13:22:41.159 226779 ERROR neutron File "/usr/lib/python3.6/site-packages/neutron/cmd/eventlet/agents/ovn_metadata.py", line 24, in main 2025-05-05 13:22:41.159 226779 ERROR neutron metadata_agent.main() 2025-05-05 13:22:41.159 226779 ERROR neutron File "/usr/lib/python3.6/site-packages/neutron/agent/ovn/metadata_agent.py", line 41, in main 2025-05-05 13:22:41.159 226779 ERROR neutron agt.start() 2025-05-05 13:22:41.159 226779 ERROR neutron File "/usr/lib/python3.6/site-packages/neutron/agent/ovn/metadata/agent.py", line 278, in start 2025-05-05 13:22:41.159 226779 ERROR neutron self.sync() 2025-05-05 13:22:41.159 226779 ERROR neutron File "/usr/lib/python3.6/site-packages/neutron/agent/ovn/metadata/agent.py", line 61, in wrapped 2025-05-05 13:22:41.159 226779 ERROR neutron return f(*args, **kwargs) 2025-05-05 13:22:41.159 226779 ERROR neutron File "/usr/lib/python3.6/site-packages/neutron/agent/ovn/metadata/agent.py", line 357, in sync 2025-05-05 13:22:41.159 226779 ERROR neutron self.provision_datapath(datapath) 2025-05-05 13:22:41.159 226779 ERROR neutron File "/usr/lib/python3.6/site-packages/neutron/agent/ovn/metadata/agent.py", line 585, in provision_datapath 2025-05-05 13:22:41.159 226779 ERROR neutron ip2.addr.delete(cidr) 2025-05-05 13:22:41.159 226779 ERROR neutron File "/usr/lib/python3.6/site-packages/neutron/agent/linux/ip_lib.py", line 544, in delete 2025-05-05 13:22:41.159 226779 ERROR neutron delete_ip_address(cidr, self.name, self._parent.namespace) 2025-05-05 13:22:41.159 226779 ERROR neutron File "/usr/lib/python3.6/site-packages/neutron/agent/linux/ip_lib.py", line 842, in delete_ip_address 2025-05-05 13:22:41.159 226779 ERROR neutron net.version, str(net.ip), net.prefixlen, device, namespace) 2025-05-05 13:22:41.159 226779 ERROR neutron File "/usr/lib/python3.6/site-packages/oslo_privsep/priv_context.py", line 247, in _wrap 2025-05-05 13:22:41.159 226779 ERROR neutron return self.channel.remote_call(name, args, kwargs) 2025-05-05 13:22:41.159 226779 ERROR neutron File "/usr/lib/python3.6/site-packages/oslo_privsep/daemon.py", line 224, in remote_call 2025-05-05 13:22:41.159 226779 ERROR neutron raise exc_type(*result[2]) 2025-05-05 13:22:41.159 226779 ERROR neutron neutron.privileged.agent.linux.ip_lib.InterfaceOperationNotSupported: Operation not supported on interface tapfae7b699-31, namespace ovnmeta-fae7b699-3086-4213-bec7-9d91737c934c. 2025-05-05 13:22:41.159 226779 ERROR neutron 2025-05-05 13:22:41.592 226810 INFO oslo_service.service [-] Parent process has died unexpectedly, exiting 2025-05-05 13:22:41.592 226809 INFO oslo_service.service [-] Parent process has died unexpectedly, exiting 2025-05-05 13:22:41.593 226810 INFO eventlet.wsgi.server [-] (226810) wsgi exited, is_accepting=True 2025-05-05 13:22:41.593 226809 INFO eventlet.wsgi.server [-] (226809) wsgi exited, is_accepting=True I can confirm that I tried assigning and deleting the IP to the interface tapfae7b699-31 from the host and from the container (podman exec -it --user root container-id bash) and succeeded. I didn't succeed to assign IP to the interface with a regular neutron user (podman exec -it container-id bash). Also, nova metadata service hosted on the controller is accessible from the compute node: [root@overcloud-computesriov-0 ~]# curl http://10.100.22.127:8775 1.0 2007-01-19 2007-03-01 2007-08-29 2007-10-10 2007-12-15 2008-02-01 2008-09-01 2009-04-04 Did anyone come across anything like this? Best regards, Davorin

3 8

[OVN][Neurton] Help in capturing metrics part of scale testing in OVN
by keerthi vassan 06 May '25

06 May '25

Hello Team Myself new to OVN with Openstack ( provider network based model) , as part of this I am trying to perform an iperf based network test to understand how traffic flow is happening. As part of that, how to validate how much time took for logical flow computation by services in hypervisor. For specific tests, looking for a way to figure out, how much services like ovn-controller, vswitchd & ovsdb server are contributing to it . Do we have any specific tooling to capture these metrics ? Can you please help with this ? Regards, Keerthivasan

2 1

[neutron] OVS Hardware Offloading Performance Issues
by Serhat Rıfat Demircan 06 May '25

06 May '25

Hello everyone, I've been testing OVS hardware offloaded ports for a while. I have ConnectX-5 and ConnectX-6 cards in my lab. Iperf tests are looking promising, but when I try to use hardware offloaded ports for krbd traffic, after some time, traffic falls back to the software path. Another interesting thing for me is without changing anything, it can also switch back to the hardware path. This issue mostly occurs while I am doing this test with 3 virtual machines on the same hypervisor. I'm not sure if this is a configuration issue or I'm hitting to cards limit. If any of you guys are experienced with this all ideas are more than welcome. Openstack version: Caracal Operation System: Ubuntu 22.04 Thank you, Serhat

1 2