- openstack-discuss - lists.openstack.org

[neutron] Bug Deputy Report July 28 - Aug 03
by Yatin Karel 05 Aug '25

05 Aug '25

Hi Neutrinos, Below is the bug deputy report for last week:- High ==== - https://bugs.launchpad.net/neutron/+bug/2119097 - [OVN] The OVN agent "metadata" extension is registering the OVN Metadata agent tags Assigned to Rodolfo Alonso - Fix Released - https://bugs.launchpad.net/neutron/+bug/2119092 - [OVN] The ``SbGlobalUpdateEvent`` event in the OVN agent should implement LP#1991817 Assigned to Rodolfo Alonso - Fix Released - https://bugs.launchpad.net/neutron/+bug/2119453 - [FT][master] test_ovs_and_ovs_events fails randomly Unassigned Medium ====== https://bugs.launchpad.net/neutron/+bug/2119093 - [OVN] The ``OVNExtensionEvent`` class is hardcoded to work only with the "metadata" extension Assigned to Rodolfo Alonso - Fix Released Invalid ===== https://bugs.launchpad.net/neutron/+bug/2119294 - [Caracal][DNSaaS] - dns_domain is empty in port show Was related to mis configurations -- Thanks and Regards Yatin Karel

1 0

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

05 Aug '25

Hello Stackers, We're eight weeks away from wrapping up the 2025.2 "Flamingo" release, and three weeks away from its feature freeze (August 28, 2025) [1]. Over the past week, no new governance changes were merged, but some new changes are undergoing community review. The nomination window for Project Team Leads and for four seats on the OpenStack Technical Committee begins on August 6, 2025 [2]. If you have any questions about the process, please post them on this mailing list or hop into #openstack-tc, #openstack-election, or #openstack-dev on OFTC and let's chat. This week, the TC is also looking to refresh the liaisons for projects governed by the "distributed-project-leadership" model—an opportunity for those teams to switch their governance styles, as well. === Weekly Meeting === The TC's weekly meeting focused on two major topics [3]: finalizing the definition of “affiliation” for TC election candidates and the next steps for retiring Monasca. On the affiliation front, we debated whether to reuse the OpenInfra bylaws language or simplify it for our needs. During the meeting, there was a consensus that the definition should focus on contributor intent and a visible employee-employer relationship without getting bogged down in legal technicalities. It's important to share our biases upfront for the sake of transparency and to strive toward the TC's affiliation diversity requirement. We are moving ahead with retiring the Monasca project. After earlier signals of interest in continuing maintenance, the project team now seems comfortable with retirement. The TC consulted this mailing list [4] to seek any further interest in the project. We'll work with the "unmaintained-core" group to clean up deliverables and code branches. We also touched on CI work to test OpenStack with Debian Bookworm and Trixie, which will help us make progress on the Eventlet removal community goal. Finally, a brief discussion ensued on OpenStack for AI, encouraging folks with architectural insight to join the Foundation's AI working group and its mailing list [5]. We wrapped with a shout out to the i18n interns and mentors for their recent progress [6]. The next weekly meeting of the TC is today, August 5, 2025, at 1700 UTC. This meeting will be hosted simultaneously over Meetpad and IRC. Please find the meeting's agenda and call details in the wiki [7]. I hope you'll be able to join us. === Governance Proposals === ==== Open for review ==== - Define "affiliation" within the context of the TC | https://review.opendev.org/c/openstack/governance/+/956024 - Add series names to runtimes doc | https://review.opendev.org/c/openstack/governance/+/955810 - Remove Monasca from active project | https://review.opendev.org/c/openstack/governance/+/953671 - os-test-images never releases | https://review.opendev.org/c/openstack/governance/+/954249 - Require declaration of affiliation from TC Candidates | https://review.opendev.org/c/openstack/governance/+/949432 === Upcoming Events === - 2025-08-06: Nominations open for OpenStack elections: https://governance.openstack.org/election/ - 2025-08-20: Nominations close for OpenStack elections - 2025-08-26: OpenInfra Days, Korea: https://2025.openinfradays.kr/ - 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-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] 2026.1 OpenStack Elections: https://governance.openstack.org/election/ [3] TC Meeting IRC Log 2025-07-29: https://meetings.opendev.org/meetings/tc/2025/tc.2025-07-29-17.00.html [4] Call for maintainers for Monasca: https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack… [5] OpenInfra AI WG List: https://lists.openinfra.org/mailman3/lists/ai-openstack-wg.lists.openinfra.… [6] i18n Internship with CMU: https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack… [7] TC Meeting Agenda, 2025-08-05: https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Next_Meeting

1 0

[qa] Proposing Sean and Tosky to Devstack core
by Ghanshyam Maan 01 Aug '25

01 Aug '25

Hello Everyone, I would like to propose adding sean-k-mooney and tosky to Devstack core team. Both have shown great knowledge and have been engaged with Devstack for a long time. Having them in the core group would help us to continue maintaining Devstack. Feel free to provide your thoughts. If there are no objections by next week, I plan to add them to the Gerrit group by Friday, August 8th. -gmaan

2 1

[Cinder] Cinder NetApp driver not working as expected on NVMe over TCP
by Vincent Godin 01 Aug '25

01 Aug '25

Hello, We have NetApp C800 arrays for our OpenStack. We have set up the Cinder configuration to use the "NVMe over TCP" protocol. We are currently seeing the following issue: - the volumes (namespaces) are correctly mounted on the hypervisors - the multipath (native) configuration is correctly handled by Cinder (this can be seen in the logs) - the volumes are only attached by a single path Looking at the NetApp driver code, and more specifically at the *nvme_library.py* file and the *initialize_connection* function, we find on line 724: portal = (target_portals[0], self.NVME_PORT, self.NVME_TRANSPORT) data = { "target_nqn": str(target_nqn), "host_nqn": host_nqn, "portals": [portal], "vol_uuid": namespace_uuid } conn_info = {"driver_volume_type": "nvmeof", "data": data} If we look at the values of the target_portals[ ], the array does indeed have all the paths available for the targeted subsystem. However, the function only returns the first path : target_portals[0] I'm not a developer, so I can't guarantee that this is the cause of the problems encountered. What is certain is that manually connecting the namespace with the nvme command does indeed yield all four paths. I'll leave the existing discussion thread that led me to this observation open. Thank you. ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ Vincent Godin <vince.mlist(a)gmail.com> 29 juil. 2025 15:53 (il y a 3 jours) À Rajat, Sean, openstack-discuss Hello, Here are some of the results on the host. An instance is launched by Openstack on the compute nvme list Node Generic SN Model Namespace Usage Format FW Rev --------------------- --------------------- -------------------- ---------------------------------------- ---------- -------------------------- ---------------- -------- /dev/nvme0n1 /dev/ng0n1 81O3QJXiLzBDAAAAAAAH NetApp ONTAP Controller 0x2 16.11 GB / 16.11 GB 4 KiB + 0 B FFFFFFFF if we have a look in the subsystem nvme list-subsys nvme-subsys0 - NQN=nqn.1992-08.com.netapp:sn.ec2c63655c3d11f0a40ad039eaba99f2:subsystem.openstack-79f1de4a-6645-4b47-9377-f06db6c2e0b5 hostnqn=nqn.2014-08.org.nvmexpress:uuid:629788a4-04c6-547c-9121-8d7a39c17fe9 iopolicy=round-robin \ +- nvme0 tcp traddr=10.10.184.3,trsvcid=4420,src_addr=10.10.184.33 live I have only one path I disconnect the subsystem manually nvme disconnect -n nqn.1992-08.com.netapp:sn.ec2c63655c3d11f0a40ad039eaba99f2:subsystem.openstack-79f1de4a-6645-4b47-9377-f06db6c2e0b5 NQN:nqn.1992-08.com.netapp:sn.ec2c63655c3d11f0a40ad039eaba99f2:subsystem.openstack-79f1de4a-6645-4b47-9377-f06db6c2e0b5 disconnected 1 controller(s) I reconnect to the subsystem with a manual command nvme connect-all -t tcp -a 10.10.186.3 nvme list Node Generic SN Model Namespace Usage Format FW Rev --------------------- --------------------- -------------------- ---------------------------------------- ---------- -------------------------- ---------------- -------- /dev/nvme0n2 /dev/ng0n2 81O3QJXiLzBDAAAAAAAH NetApp ONTAP Controller 0x2 16.11 GB / 16.11 GB 4 KiB + 0 B FFFFFFFF And if we look at the subsystem nvme list-subsys nvme-subsys0 - NQN=nqn.1992-08.com.netapp:sn.ec2c63655c3d11f0a40ad039eaba99f2:subsystem.openstack-79f1de4a-6645-4b47-9377-f06db6c2e0b5 hostnqn=nqn.2014-08.org.nvmexpress:uuid:629788a4-04c6-547c-9121-8d7a39c17fe9 iopolicy=round-robin \ +- nvme5 tcp traddr=10.10.184.3,trsvcid=4420,src_addr=10.10.184.33 live +- nvme4 tcp traddr=10.10.186.3,trsvcid=4420,src_addr=10.10.186.33 live +- nvme3 tcp traddr=10.10.184.4,trsvcid=4420,src_addr=10.10.184.33 live +- nvme2 tcp traddr=10.10.186.4,trsvcid=4420,src_addr=10.10.186.33 live As you can see, i have four paths Configuration details about multipath : - in nova.conf [libvirt] volume_use_multipath = True - in cinder.conf [DEFAULT] target_protocol = nvmet_tcp ... [netapp-backend] use_multipath_for_image_xfer = True netapp_storage_protocol = nvme ... /sys/module/nvme_core/parameters/multipath cat /sys/module/nvme_core/parameters/multipath Y nova-compute.log grep -i get_connector_properties /var/log/kolla/nova/nova-compute.log 2025-07-29 14:09:51.553 7 DEBUG os_brick.initiator.connectors.lightos [None req-faf2b0ca-0709-4a70-8302-fa90ad293fd3 4e2ddaf17ee747f2a1f03a392943f80a cb513debb0834ec5b6588356a960bad9 - - default default] LIGHTOS: finally hostnqn: nqn.2014-08.org.nvmexpress:uuid:629788a4-04c6-547c-9121-8d7a39c17fe9 dsc: get_connector_properties /var/lib/kolla/venv/lib/python3.12/site-packages/os_brick/initiator/connectors/lightos.py:115 2025-07-29 14:09:51.553 7 DEBUG os_brick.utils [None req-faf2b0ca-0709-4a70-8302-fa90ad293fd3 4e2ddaf17ee747f2a1f03a392943f80a cb513debb0834ec5b6588356a960bad9 - - default default] <== get_connector_properties: return (30ms) {'platform': 'x86_64', 'os_type': 'linux', 'ip': '10.10.52.161', 'host': 'pkc-dcp-cpt-03', *'multipath': True, 'enforce_multipath': True*, 'initiator': 'iqn.2004-10.com.ubuntu:01:d0bb7aa9bcf1', 'do_local_attach': False, 'nvme_hostid': '5ca8b6d2-aa7d-42d8-bf74-c18484fab68c', 'system uuid': '31343550-3939-5a43-4a44-305930304c48', 'nqn': 'nqn.2014-08.org.nvmexpress:uuid:629788a4-04c6-547c-9121-8d7a39c17fe9', *'nvme_native_multipath': True*, 'found_dsc': '', 'host_ips': ['10.20.128.33', '10.10.184.33', '10.10.186.33', '10.10.52.161', '10.10.22.161', '10.234.2.161', '10.10.50.161', '172.17.0.1', 'fe80::7864:3eff:fe13:5e1f', 'fe80::fc16:3eff:fe7f:3430', 'fe80::4c20:48ff:fe0f:2660']} trace_logging_wrapper /var/lib/kolla/venv/lib/python3.12/site-packages/os_brick/utils.py:204 multipathd systemctl status multipathd.service ○ multipathd.service Loaded: masked (Reason: Unit multipathd.service is masked.) Active: inactive (dead) If you can see some reason to explain why openstack connect to the subsystem only with one path !!! Thanks ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ Rajat Dhasmana 30 juil. 2025 12:37 (il y a 2 jours) À moi, Sean, openstack-discuss On Wed, Jul 30, 2025 at 3:15 PM Vincent Godin <vince.mlist(a)gmail.com> wrote: > Hello guys, > > Some more informations found in the nova-compute.log : > > -try iscsi > > 2025-07-29 14:09:51.523 1222 DEBUG oslo_concurrency.processutils [-] > Running cmd (subprocess): cat /etc/iscsi/initiatorname.iscsi execute > /var/lib/kolla/venv/lib/python3.12/site-packages/oslo_concurrency/processutils.py:349 > 2025-07-29 14:09:51.528 1222 DEBUG oslo_concurrency.processutils [-] CMD > "cat /etc/iscsi/initiatorname.iscsi" returned: 0 in 0.005s execute > /var/lib/kolla/venv/lib/python3.12/site-packages/oslo_concurrency/processutils.py:372 > 2025-07-29 14:09:51.528 1222 DEBUG oslo.privsep.daemon [-] privsep: > reply[90a51cdb-5701-4339-b059-fefb0b79b7a5]: (4, ('## DO NOT EDIT OR REMOVE > THIS FILE!\n## If you remove this file, the iSCSI daemon will not > start.\n## If you change the InitiatorName, existing access control > lists\n## may reject this initiator. The InitiatorName must be unique\n## > for each iSCSI initiator. Do NOT duplicate iSCSI > InitiatorNames.\nInitiatorName=iqn.2004-10.com.ubuntu:01:d0bb7aa9bcf1\n', > '')) _call_back > /var/lib/kolla/venv/lib/python3.12/site-packages/oslo_privsep/daemon.py:503 > > -try lightos ??? > > 2025-07-29 14:09:51.552 7 DEBUG os_brick.initiator.connectors.lightos > [None req-faf2b0ca-0709-4a70-8302-fa90ad293fd3 > 4e2ddaf17ee747f2a1f03a392943f80a cb513debb0834ec5b6588356a960bad9 - - > default default] LIGHTOS: [Errno 111] ECONNREFUSED find_dsc > /var/lib/kolla/venv/lib/python3.12/site-packages/os_brick/initiator/connectors/lightos.py:135 > 2025-07-29 14:09:51.553 7 INFO os_brick.initiator.connectors.lightos [None > req-faf2b0ca-0709-4a70-8302-fa90ad293fd3 4e2ddaf17ee747f2a1f03a392943f80a > cb513debb0834ec5b6588356a960bad9 - - default default] Current host hostNQN > nqn.2014-08.org.nvmexpress:uuid:629788a4-04c6-547c-9121-8d7a39c17fe9 and > IP(s) are ['10.20.128.33', '10.10.184.33', '10.10.186.33', '10.10.52.161', > '10.10.22.161', '10.234.2.161', '10.10.50.161', '172.17.0.1', > 'fe80::7864:3eff:fe13:5e1f', 'fe80::fc16:3eff:fe7f:3430', > 'fe80::4c20:48ff:fe0f:2660'] > 2025-07-29 14:09:51.553 7 DEBUG os_brick.initiator.connectors.lightos > [None req-faf2b0ca-0709-4a70-8302-fa90ad293fd3 > 4e2ddaf17ee747f2a1f03a392943f80a cb513debb0834ec5b6588356a960bad9 - - > default default] LIGHTOS: did not find dsc, continuing anyway. > get_connector_properties > /var/lib/kolla/venv/lib/python3.12/site-packages/os_brick/initiator/connectors/lightos.py:112 > 2025-07-29 14:09:51.553 7 DEBUG os_brick.initiator.connectors.lightos > [None req-faf2b0ca-0709-4a70-8302-fa90ad293fd3 > 4e2ddaf17ee747f2a1f03a392943f80a cb513debb0834ec5b6588356a960bad9 - - > default default] LIGHTOS: finally hostnqn: > nqn.2014-08.org.nvmexpress:uuid:629788a4-04c6-547c-9121-8d7a39c17fe9 dsc: > get_connector_properties > /var/lib/kolla/venv/lib/python3.12/site-packages/os_brick/initiator/connectors/lightos.py:115 > > -then > > 2025-07-29 14:09:51.553 7 DEBUG os_brick.utils [None > req-faf2b0ca-0709-4a70-8302-fa90ad293fd3 4e2ddaf17ee747f2a1f03a392943f80a > cb513debb0834ec5b6588356a960bad9 - - default default] <== > get_connector_properties: return (30ms) {'platform': 'x86_64', 'os_type': > 'linux', 'ip': '10.10.52.161', 'host': 'pkc-dcp-cpt-03', 'multipath': True, > 'enforce_multipath': True, 'initiator': > 'iqn.2004-10.com.ubuntu:01:d0bb7aa9bcf1', 'do_local_attach': False, > 'nvme_hostid': '5ca8b6d2-aa7d-42d8-bf74-c18484fab68c', 'system uuid': > '31343550-3939-5a43-4a44-305930304c48', 'nqn': > 'nqn.2014-08.org.nvmexpress:uuid:629788a4-04c6-547c-9121-8d7a39c17fe9', > 'nvme_native_multipath': True, 'found_dsc': '', 'host_ips': > ['10.20.128.33', '10.10.184.33', '10.10.186.33', '10.10.52.161', > '10.10.22.161', '10.234.2.161', '10.10.50.161', '172.17.0.1', > 'fe80::7864:3eff:fe13:5e1f', 'fe80::fc16:3eff:fe7f:3430', > 'fe80::4c20:48ff:fe0f:2660']} trace_logging_wrapper > /var/lib/kolla/venv/lib/python3.12/site-packages/os_brick/utils.py:204 > 'multipath': True, 'enforce_multipath': True This shows that multipath configuration is set correctly. It would be good to search for this log entry[1] in cinder-volume logs and see the *portals *field to verify how many portals does the netapp nvme driver returns *Initialize connection info:* https://github.com/openstack/cinder/blob/master/cinder/volume/drivers/netap… > 2025-07-29 14:09:51.554 7 DEBUG nova.virt.block_device [None > req-faf2b0ca-0709-4a70-8302-fa90ad293fd3 4e2ddaf17ee747f2a1f03a392943f80a > cb513debb0834ec5b6588356a960bad9 - - default default] [instance: > 3fcb3e36-1890-44f7-9c3c-283c05e91910] Updating existing volume attachment > record: b81aea6e-f2ae-4781-8c2e-3b7f1606ba0d _volume_attach > /var/lib/kolla/venv/lib/python3.12/site-packages/nova/virt/block_device.py:666 > 2025-07-29 14:09:53.680 7 DEBUG os_brick.initiator.connectors.nvmeof [None > req-faf2b0ca-0709-4a70-8302-fa90ad293fd3 4e2ddaf17ee747f2a1f03a392943f80a > cb513debb0834ec5b6588356a960bad9 - - default default] ==> connect_volume: > call "{'self': <os_brick.initiator.connectors.nvmeof.NVMeOFConnector object > at 0x7cf65c576090>, 'connection_properties': {'target_nqn': > 'nqn.1992-08.com.netapp:sn.ec2c63655c3d11f0a40ad039eaba99f2:subsystem.openstack-79f1de4a-6645-4b47-9377-f06db6c2e0b5', > 'host_nqn': > 'nqn.2014-08.org.nvmexpress:uuid:629788a4-04c6-547c-9121-8d7a39c17fe9', > 'portals': [['10.10.184.3', 4420, 'tcp']], 'vol_uuid': > '69da9918-7e84-4ee4-b7bb-9b50e3e6d739', 'qos_specs': None, 'access_mode': > 'rw', 'encrypted': False, 'cacheable': False, 'enforce_multipath': True}}" > trace_logging_wrapper > /var/lib/kolla/venv/lib/python3.12/site-packages/os_brick/utils.py:177 > 'portals': [['10.10.184.3', 4420, 'tcp']] Here we can see that there is only one portal returned by the netapp driver

1 0

[Neutron] - General thoughts on tenancy network MTU
by Karl Kloppenborg 01 Aug '25

01 Aug '25

Hi Neutrinos, I was discussing with a colleague about our MTU settings within our Openstack regions, generally speaking we have a physnet_global_mtu of 1550 with tenancy networks automatically provisioned as 1500 VXLAN. This ends up with VM’s receiving DHCP MTU settings of 1500 which is fine, however reading about yesterday’s discussion on OVN performance, Nguyen’s recommendation was to enable Jumboframes. This got me thinking, what do you set your tenancy and phynet MTU’s to? Very interested to hear about your experiences with running 9k MTU’s on the VM networks etc, what impact this has on OVS/OVN routers and northbound connectivity being 1500. Thanks, Karl. Karl Kloppenborg Chief Technology Officer m: +61 437 239 565 resetdata.com<https://resetdata.com/> [cid:reset_69557fc2-1d63-4932-b5fd-93bd4f39ca7b.png] ResetData supports Mandatory Client Related Financial Disclosures – Scope 3 Emissions Reporting For more information on the phasing of these requirements for business please visit; https://treasury.gov.au/sites/default/files/2024-01/c2024-466491-policy-sta…<https://treasury.gov.au/sites/default/files/2024-01/c2024-466491-policy-sta…> This email transmission is intended only for the addressee / person responsible for delivery of the message to such person and may contain confidential or privileged information. Confidentiality and legal privilege are not waived or lost by reason of mistaken delivery to you, nor may you use, review, disclose, disseminate or copy any information contained in or attached to it. Whilst this email has been checked for viruses, the sender does not warrant that any attachments are free from viruses or other defects. You assume all liability for any loss, damage or other consequences which may arise from opening or using the attachments. If you received this e-mail in error please delete it and any attachments and kindly notify us by immediately sending an email to contact(a)resetdata.com.au<mailto:contact@resetdata.com.au>

2 1

(Ceilometer) Openstack - Kolla-Ansible deployment - Ceilometer (Central & compute) Docker Containers are unhealthy
by TRB PREM KUMAR 01 Aug '25

01 Aug '25

Hi, We have deployed an all-in-one OpenStack server for billing. Now ceilometer containers are unhealthy. Please help us to resolve this issue. Reference Output for reference: trb1@openstack-aio-01:~$ docker ps | grep ceil c53fc69ba42b quay.io/openstack.kolla/ceilometer-compute:2024.2-rocky-9 "dumb-init --single-…" About a minute ago Up About a minute *(unhealthy) * ceilometer_compute 9337af646e0f quay.io/openstack.kolla/ceilometer-central:2024.2-rocky-9 "dumb-init --single-…" 30 minutes ago Up About a minute ( *unhealthy)* ceilometer_central 554c4b8ccd86 quay.io/openstack.kolla/ceilometer-notification:2024.2-rocky-9 "dumb-init --single-…" 4 days ago Up About a minute (healthy) ceilometer_notification *** Logs files are attached for reference. Regards, TRB.

3 6

[neutron] Drivers meeting canceled Friday, August 1st
by Brian Haley 01 Aug '25

01 Aug '25

Hello Neutrinos: I am going to cancel tomorrow's Drivers meetings as there is no 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

[scientific-sig][help] Research about private cloud
by Winicius Allan 31 Jul '25

31 Jul '25

Hi all! I'm about to write my final paper, and I want to research something related to OpenStack and private clouds. If someone wants to take the time to discuss the problems in your environment, I'd be very glad!What I had on my mind is: - There is something that could improve utilization and performance when the user is not charged about their use on a private cloud. - There is any process scheduling algorithm that could be used on specific workloads instead of Linux default scheduler that can improve application performance? I was thinking about using eBPF here. Best regards.

2 1

[cinder] AttributeError: 'Volume' object has no attribute 'use_quota'
by Kees Meijs | Nefos 31 Jul '25

31 Jul '25

Hello Stackers, It seems we're hitting a bug within the Cinder Volume service. The problem presents itself when creating a Ceph RBD backed Volume using an originating snapshot. > 2025-07-31 19:02:54.896 3602390 WARNING cinder.volume.manager > [req-a476ac04-ee6c-4335-8fca-e606616a5959 > eccdb27249254d9d9fb73570f5de8877 d678ba8e1dee4f7484555580d0a61562 - - > -] Task > 'cinder.volume.flows.manager.create_volume.CreateVolumeFromSpecTask;volume:create' > (03c06b47-7df3-4427-8ad0-61f9a97d0159) transitioned into state > 'FAILURE' from state 'RUNNING' > 5 predecessors (most recent first): > </snip (maybe the Atoms are needed and if so I could redact those)> > |__Flow 'volume_create_manager': AttributeError: 'Volume' > object has no attribute 'use_quota' > 2025-07-31 19:02:54.896 3602390 ERROR cinder.volume.manager Traceback > (most recent call last): > 2025-07-31 19:02:54.896 3602390 ERROR cinder.volume.manager File > "/usr/lib/python3/dist-packages/taskflow/engines/action_engine/executor.py", > line 53, in _execute_task > 2025-07-31 19:02:54.896 3602390 ERROR cinder.volume.manager result = > task.execute(**arguments) > 2025-07-31 19:02:54.896 3602390 ERROR cinder.volume.manager File > "/usr/lib/python3/dist-packages/cinder/volume/flows/manager/create_volume.py", > line 1158, in execute > 2025-07-31 19:02:54.896 3602390 ERROR cinder.volume.manager > model_update = self._create_from_snapshot(context, volume, > 2025-07-31 19:02:54.896 3602390 ERROR cinder.volume.manager File > "/usr/lib/python3/dist-packages/cinder/volume/flows/manager/create_volume.py", > line 461, in _create_from_snapshot > 2025-07-31 19:02:54.896 3602390 ERROR cinder.volume.manager > model_update = self.driver.create_volume_from_snapshot(volume, > 2025-07-31 19:02:54.896 3602390 ERROR cinder.volume.manager File > "/usr/lib/python3/dist-packages/cinder/volume/drivers/rbd.py", line > 1069, in create_volume_from_snapshot > 2025-07-31 19:02:54.896 3602390 ERROR cinder.volume.manager if > int(volume.size): > 2025-07-31 19:02:54.896 3602390 ERROR cinder.volume.manager > AttributeError: 'Volume' object has no attribute 'use_quota' > 2025-07-31 19:02:54.896 3602390 ERROR cinder.volume.manager Yes, this reflects a non-current version, to be precise Cinder 17.4. However, does this look familiar to someone, maybe? Thanks! Cheers, Kees

1 1

[Neutron] ML2: Can Operators Safely Extend binding:profile with Custom Keys?
by cxue22＠bloomberg.net 31 Jul '25

31 Jul '25

Hi all, I'm working on a Neutron customization to expose and manage data in the `binding:profile` field stored in the `ml2_port_bindings` table, and I have a few questions around operator and third-party plugin compatibility — particularly in reference to the blueprint: https://blueprints.launchpad.net/neutron/+spec/ml2-binding-profile As I understand it, the `binding:profile` is represented as a string column containing a JSON dictionary that can be passed by the compute agent and interpreted by ML2 mechanism drivers during port binding. My intent is to: - Create a custom API endpoint that allows reading and updating specific key/value pairs in this JSON dictionary. - Enable third-party mechanism drivers and operators to add custom fields to this profile. My main question is: **Are operators and third-party ML2 drivers free to add arbitrary key/value pairs to the `binding:profile` dictionary, and can those be expected to persist across Neutron upgrades and database migrations?** Additionally: - Are there any best practices or expectations around namespacing or schema validation of custom fields in `binding:profile`? - Are there known caveats or upgrade scenarios where such data may be truncated, filtered, or overwritten? I'd appreciate any guidance from the Neutron community on how this field is intended to be extended or preserved, and whether such customization is supported in the long term. Thanks in advance! Best regards, Chang Xue Bloomberg Engineering

3 3

[openstack][magnum]Cannot upgrade clusters
by Nguyễn Hữu Khôi 31 Jul '25

31 Jul '25

Hello. I cannot upgrade clusters via magnum_cluster_api. These are log from magnum_api: https://anotepad.com/notes/c9h8bd55 OPS: 2025.1 OS: Ubuntu 24.04 magnum_cluster_api: v0.30.0 Would you give some ideas on it? Thank you! Nguyen Huu Khoi

1 1

[Neutron][VPNaaS] Multiple tunnels per IPSec Service
by Shubham Yadav 31 Jul '25

31 Jul '25

Hello OpenStack Community, I'm working with OpenStack VPNaaS (using strongSwan as the backend driver) and have a question about tunnel configuration capabilities. *Current Setup:* OpenStack VPNaaS with strongSwan driver (StrongSwanDriver) Single VPN Service (gateway) with multiple IPSec Site Connections Each connection targets different remote peers with distinct subnets *Configuration Details:* VPN Service: Connected to a single router Multiple IPSec Site Connections under the same VPN Service: Connection 1: To MY office (10.10.100.0/24) via peer 68.x.y.34 Connection 2: To Rackspace (172.24.60.0/22) via peer 184.n.p.53 Shared IKE and IPSec policies across connections Local endpoint groups covering multiple subnets (192.168.0.0/24, 10.43.0.0/16) *Question:*Is it supported/recommended to have multiple IPSec Site Connections under a single VPN Service? I understand this creates multiple tunnels from the same OpenStack router to different remote peers. *Current Issue:*One of my connections shows "PENDING_CREATE" status while the other is "ACTIVE". I'm trying to determine if this is: A configuration issue on my end A limitation of having multiple tunnels per VPN service A strongSwan-specific behavior in the OpenStack context *Specific Questions:* Does VPNaaS officially support multiple IPSec connections per VPN Service? Are there any known limitations or best practices when using multiple tunnels? Should each remote site have its own dedicated VPN Service instead? I've checked the documentation but couldn't find clear guidance on multi-tunnel scenarios. Any insights from the community would be greatly appreciated. *Environment:* OpenStack version: 2024.2 Dalmatian Neutron VPNaaS with strongSwan backend Kubernetes-deployed OpenStack (OpenStack-Helm) Thank you for your time and assistance! Best regards, Shubham

1 0

[Neutron][VPNaaS] Multiple tunnels per IPSec Service
by Shubham Yadav 31 Jul '25

31 Jul '25

Hello OpenStack Community, I'm working with OpenStack VPNaaS (using strongSwan as the backend driver) and have a question about tunnel configuration capabilities. Current Setup: OpenStack VPNaaS with strongSwan driver (StrongSwanDriver) Single VPN Service (gateway) with multiple IPSec Site Connections Each connection targets different remote peers with distinct subnets Configuration Details: VPN Service: Connected to a single router Multiple IPSec Site Connections under the same VPN Service: Connection 1: To MY office (10.10.100.0/24) via peer 68.x.y.34 Connection 2: To Rackspace (172.24.60.0/22) via peer 184.n.p.53 Shared IKE and IPSec policies across connections Local endpoint groups covering multiple subnets (192.168.0.0/24, 10.43.0.0/16) Question: Is it supported/recommended to have multiple IPSec Site Connections under a single VPN Service? I understand this creates multiple tunnels from the same OpenStack router to different remote peers. Current Issue: One of my connections shows "PENDING_CREATE" status while the other is "ACTIVE". I'm trying to determine if this is: A configuration issue on my end A limitation of having multiple tunnels per VPN service A strongSwan-specific behavior in the OpenStack context Specific Questions: Does VPNaaS officially support multiple IPSec connections per VPN Service? Are there any known limitations or best practices when using multiple tunnels? Should each remote site have its own dedicated VPN Service instead? I've checked the documentation but couldn't find clear guidance on multi-tunnel scenarios. Any insights from the community would be greatly appreciated. Environment: OpenStack version: 2024.2 Dalmatian Neutron VPNaaS with strongSwan backend Kubernetes-deployed OpenStack (OpenStack-Helm) Thank you for your time and assistance! Best regards, Shubham

1 0

[Ovs-dpdk]Issue with ovs-dpdk deployment in Kolla-Ansible (zed)
by samira_darvishnia＠yahoo.com 31 Jul '25

31 Jul '25

Hi all, I'm trying to deploy OVS-DPDK using Kolla-Ansible Zed, and I'm running into a blocking issue during deployment. I would really appreciate your insights or suggestions. Problem Summary: During the deployment of ovs-dpdk, the container ovsdpdk-vswitchd fails to start, with the following error in its logs: + echo 'Running command: '\''/usr/sbin/ovs-vswitchd unix:/run/openvswitch/db.sock -vconsole:emer -vsyslog:err -vfile:info --mlockall --log-file=/var/log/kolla/openvswitch/ovs-vswitchd.log --pidfile'\''' + exec /usr/sbin/ovs-vswitchd unix:/run/openvswitch/db.sock -vconsole:emer -vsyslog:err -vfile:info --mlockall --log-file=/var/log/kolla/openvswitch/ovs-vswitchd.log --pidfile Running command: '/usr/sbin/ovs-vswitchd unix:/run/openvswitch/db.sock -vconsole:emer -vsyslog:err -vfile:info --mlockall --log-file=/var/log/kolla/openvswitch/ovs-vswitchd.log --pidfile' ovs-vswitchd: invalid option -- 'w' ovs-vswitchd: invalid option -- 'w' EAL: FATAL: Invalid 'command line' arguments. 2025-07-30T13:44:59Z|00017|dpdk|EMER|Unable to initialize DPDK: Invalid argument ovs-vswitchd: Cannot init EAL (Invalid argument) This appears to be related to an incorrect parsing of arguments for ovs-vswitchd. What I’ve tried: I already applied this patch (as referenced in Gerrit): https://review.opendev.org/c/openstack/kolla-ansible/+/913653/1/ansible/rol… However, the issue still persists. Additional context: • Deployment hangs on the task: name: Wait for dpdk tunnel ip It waits for 5 minutes and then fails. • The parameter dpdk_tunnel_interface_address is already set in my global.yml. • I’ve configured and bound NICs to vfio-pci. • Environment info: • OpenStack Zed • Kolla-Ansible Zed • dpdk_tunnel_interface_address is set • OVS-DPDK is containerized via Kolla Has anyone seen this issue before or can suggest further steps? Any insight on how to correctly pass EAL arguments or what else might be misconfigured would be very helpful. Thanks in advance, Samira

1 0

[Neutron][Tacker][Issue Investigation] Issue with Neutron in Tacker Zuul Patches �C Suspected Regression in Neutron Master Branch
by Renu Rani 31 Jul '25

31 Jul '25

Hi Neutron Team, We are currently facing an issue in Tacker Zuul patch jobs build (with master branch), where the DevStack setup fails during the initial Neutron network creation step. Problem statement: The failure occurs at this point in the stack.sh script, for devstack environment creation in build process. Below command execution is failing in stack.sh [openstack --os-cloud devstack-admin-demo --os-region RegionOne router add subnet 20b264df-5f19-4599-a83d-2e76e7cbf5dc d777d04b-93ff-4e94-b6a9-cc8de3e23921] Error Message: This results in a 500 Internal Server Error, as seen in the logs: [HttpException: 500: Server Error for url: http://10.x.x.x/networking/v2.0/routers/20b264df-5f19-4599-a83d-2e76e7cbf5d…] Analysis for the issue: Below error is coming in Neutron API logs: [ERROR neutron.plugins.ml2.ovo_rpc RuntimeError: cannot notify on un-acquired lock] 1. Tried overriding the required-projects in Zuul to use stable/2025.1 branches (instead of master) to identify project(master branch) which is causing root cause. 2. Tacker team has created DNM patch (952892) to invetsigate this in detail. https://review.opendev.org/c/openstack/tacker/+/952892 1. In DNM patch Patchset 11 (on June 29), we have taken devstack stable/2025.1. In stable branch the devstack environment created sucessfully. 2. In DNM patch Patchset 25 (on July 8), with the same devstack override (stable/2025.1), the job now fails earlier during DevStack setup. The logs show that Neutron failed to start, causing the job to fail across all nodes. As per observations and anlysis seems the recent changes in the Neutron master branch between June 29 and July 8 might be causing this issue. We’d appreciate your help in reviewing the changes in Neutron's master branch during that window that could cause this behavior and suggesting any debugging approaches or patches we can test on tacker. Please let us know if you'd like additional logs or info from the Zuul job runs. Thanks in advance for your support! Thanks & Regards, Renu Rani (レヌラニ) Mobile: +91-9311888962 E-mail: renu.rani(a)india.nec.com<mailto:renu.rani@india.nec.com> The contents of this e-mail and any attachment(s) are confidential and intended for the named recipient(s) only. It shall not attach any liability on the originator or NEC Corporation India Private Limited or its affiliates. Any views or opinions presented in this email are solely those of the author and may not necessarily reflect the opinions of NEC Corporation India Private Limited or its affiliates. Any form of reproduction, dissemination, copying, disclosure, modification, distribution and / or publication of this message without the prior written consent of the author of this e-mail is strictly prohibited. If you have received this email in error please delete it and notify the sender immediately.

5 10

[neutron] Is NVIDIA ASAP2 offloading with OpenStack just a myph?
by Vasyl Saienko 30 Jul '25

30 Jul '25

Hello OpenStack community, I'm trying to set up OpenStack with Nvidia ASAP2 hardware offloading in switchdev mode according to OpenStack guidelines <https://docs.openstack.org/neutron/latest/admin/config-ovs-offload.html> and Nvidia guidelines <https://docs.nvidia.com/doca/sdk/ovs-kernel+hardware+offloads/index.html> on the ConnectX6DX. I've tried different network types VLAN and VXLAN but offloading for none of them works. From an OpenStack standpoint everything is configured according to documentation, representor device is created and plugged in the br-int bridge (eth14) physical. PF enp33s0f0np0 is set to switchdev mode ``` devlink dev eswitch show pci/0000:21:00.0 pci/0000:21:00.0: mode switchdev inline-mode none encap-mode basic ``` ``` root@kaas-node-52648a8f-cbfd-4b9a-b392-1594b1d97cfa:~# ovs-vsctl show 12e00cdb-6520-4666-908f-57f59e8b9bd4 Manager "ptcp:6640:127.0.0.1" is_connected: true Bridge br-ex Controller "tcp:127.0.0.1:6633" is_connected: true fail_mode: secure datapath_type: system Port br-ex Interface br-ex type: internal Port pr-floating Interface pr-floating Port phy-br-ex Interface phy-br-ex type: patch options: {peer=int-br-ex} Bridge br-int Controller "tcp:127.0.0.1:6633" is_connected: true fail_mode: secure datapath_type: system Port patch-tun Interface patch-tun type: patch options: {peer=patch-int} Port br-int Interface br-int type: internal Port int-br-tenant Interface int-br-tenant type: patch options: {peer=phy-br-tenant} Port tap58ac2b17-fb tag: 1 Interface tap58ac2b17-fb Port int-br-ex Interface int-br-ex type: patch options: {peer=phy-br-ex} Port eth14 tag: 1 Interface eth14 Bridge br-tenant Controller "tcp:127.0.0.1:6633" is_connected: true fail_mode: secure datapath_type: system Port br-tenant Interface br-tenant type: internal Port phy-br-tenant Interface phy-br-tenant type: patch options: {peer=int-br-tenant} Port enp33s0f0np0 Interface enp33s0f0np0 Bridge br-tun Controller "tcp:127.0.0.1:6633" is_connected: true fail_mode: secure datapath_type: system Port br-tun Interface br-tun type: internal Port patch-int Interface patch-int type: patch options: {peer=patch-tun} ovs_version: "3.0.0-0056-25.04-based-3.3.5" ``` But hardware offloading is not happening, tcpdump on eth14 still shows all packets, and no TC rules are created. OpenStack uses complex openvswitch rules to setup virtual networking, in this scenario vlan tagging is done by the following rule ``` cookie=0x45b91976d5c4f175, duration=233.443s, table=60, n_packets=314, n_bytes=35574, priority=100,in_port=eth14 actions=set_field:0x11->reg5,set_field:0x1->reg6,resubmit(,73) ``` If we simplify openflow rules and align them with Nvidia guidelines for openvswitch hardware offloading by plugging representor device directly into physnet bridge, and assign vlan tag as port attribute hardware offloading starts working. ``` root@kaas-node-52648a8f-cbfd-4b9a-b392-1594b1d97cfa:~# ovs-vsctl del-port eth14 root@kaas-node-52648a8f-cbfd-4b9a-b392-1594b1d97cfa:~# ovs-vsctl add-port br-tenant eth14 root@kaas-node-52648a8f-cbfd-4b9a-b392-1594b1d97cfa:~# ovs-vsctl set port eth14 tag=1443 ``` ``` root@kaas-node-52648a8f-cbfd-4b9a-b392-1594b1d97cfa:~# for i in $(ip link | awk '{print $2}' |grep -e enp -e ens |grep -v vf$); do tc filter show dev $i ingress; done filter protocol 802.1Q pref 6 flower chain 0 filter protocol 802.1Q pref 6 flower chain 0 handle 0x1 vlan_id 1443 vlan_prio 0 vlan_ethtype arp dst_mac fa:16:3e:36:1b:90 src_mac fa:16:3e:39:90:d8 eth_type arp in_hw in_hw_count 1 action order 1: vlan pop pipe index 1 ref 1 bind 1 no_percpu used_hw_stats delayed action order 2: mirred (Egress Redirect to device eth14) stolen index 1 ref 1 bind 1 cookie 4b5b5a701f4e3fee7ac1c198037522e3 no_percpu used_hw_stats delayed ``` Similar issue occurs when using the VXLAN network. OpenStack setup VXLAN tunnel like, where tunnel_id is inserted dynamically via openflow rules (in_key=flow) ``` Port vxlan-0a0c0004 Interface vxlan-0a0c0004 type: vxlan options: {df_default="true", dst_port="4790", egress_pkt_mark="0", in_key=flow, local_ip="10.12.0.9", out_key=flow, remote_ip="10.12.0.4"} ``` In this configuration hardware offloading is not happening neither. But when setting up vxlan according to nvidia guidelines (no complex rules are involved) hardware offloading starts working (tcpdump for representor device shows only first packet and tc rules are being created). ``` Port vxlan3 Interface vxlan3 type: vxlan options: {key="60987", local_ip="10.12.0.9", remote_ip="10.12.0.4"} ``` ``` Cannot find device "enp33s0f0npf0vf" Cannot find device "veth68d427d@if1" filter protocol ip pref 2 flower chain 0 filter protocol ip pref 2 flower chain 0 handle 0x1 dst_mac fa:16:3e:65:0c:6d src_mac 52:5a:d0:9e:8a:32 eth_type ipv4 enc_dst_ip 10.12.0.9 enc_src_ip 10.12.0.8 enc_key_id 60987 enc_dst_port 4789 enc_tos 0 ip_flags nofrag in_hw in_hw_count 2 action order 1: tunnel_key unset pipe index 2 ref 1 bind 1 no_percpu used_hw_stats delayed action order 2: mirred (Egress Redirect to device eth15) stolen index 2 ref 1 bind 1 cookie 5d44cdf6754fc237cc0bd688a6fe70a8 no_percpu used_hw_stats delayed ``` Am I doing something wrong? Is there anyone who has other results? -- <https://www.mirantis.com/> Vasyl Saienko Principal DevOps Engineer vsaienko(a)mirantis.com <dstoltenberg(a)mirantis.com> +(380) 66 072 07 17 <++1+(650)+564+7038>

3 3

Openstack integration with openid as leycloak
by amine belroul 30 Jul '25

30 Jul '25

Hello, Is there any detailed docs can help me to integrate openstack with openid? Please multi domains and multi projects.

3 2

[Cinder] pbm configuring multipath on NVMeoF
by Vincent Godin 30 Jul '25

30 Jul '25

Hello guys, Openstack: 2025.1 OS: Ubuntu 24.04 We are having trouble configuring multipath on a NetApp backend using NVMe over TCP. After reading numerous articles on this issue, we concluded that it was necessary to operate in native multipath mode, which is enabled by default on Ubuntu 24.04, and that it is no longer necessary to keep the multipathd service active for this to work. We ran inconclusive tests by setting the "use_multipath_for_image_xfer" and "enforce_multipath_for_image_xfer" variables to true in cinder.conf. We also set the "volume_use_multipath variable" to true in the libvirt section of nova.conf, but without success. After creating an instance and a volume on a server with Openstack, when querying the subsystem with the nvme command, we only get a single path. But when we query the backend from the same server with "nvme discover," we do get four paths. In the os-brick code, we see that it checks a Multipath variable that must be set to true... I think this is purely a configuration issue, but the examples given by various manufacturers (NetApp, PureStorage, etc.) don't indicate anything in particular. So, does anyone know the configuration to apply for multipath to work (cinder/nova)? Thank you.

3 8

OpenStack for AI Whitepaper
by Kendall Nelson 30 Jul '25

30 Jul '25

Hello Folks! As you might have heard, the OpenInfra AI WG has been starting to put together an OpenStack for AI Whitepaper and we wanted to formally invite you all to attend the WG's meetings and working sessions, to get involved on working group's the mailing list <https://lists.openinfra.org/mailman3/lists/ai-openstack-wg.lists.openinfra.…> and to help us shape the whitepaper into a resource for those looking to understand just how OpenStack is capable of serving AI workloads. We could really benefit from your innate understanding of how the OpenStack services work and also hope to surface feedback and questions from the group for the larger OpenStack community in future meetings. Also, we have organizations volunteering to do show and tell sessions about their OpenStack clouds hosting AI workloads and discussing pain points, lessons learned etc. The next of those show and tell sessions will take place on September 29. We have a meeting coming this week on Thursday at 13 UTC in this google meet <http://meet.google.com/wzn-jgcn-cfj>. If you would like an actual calendar invite, please reach out and I will make sure you are added! -- Kendall Nelson *Senior Upstream Developer Advocate* The OpenInfra Foundation <https://openinfra.dev/>

1 1

[kolla] IRC meeting cancelled - 30-th of July 2025
by Bartosz Bezak 29 Jul '25

29 Jul '25

Hello, Due to limited availability of the Kolla core team members, tomorrow’s Kolla IRC meeting is cancelled. Best regards, Bartosz Bezak

1 0

[publiccloud-sig] Public Cloud SIG meeting d.d. 30 July
by Kees Meijs | Nefos 29 Jul '25

29 Jul '25

Hello Stackers, Tomorrow (that's 30 July) 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 tomorrow! 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

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

29 Jul '25

Hello Stackers, We're a month away from the feature freeze date for the 2025.2 ("Flamingo") release cycle [1], scheduled for 2025-08-28. OpenStack project teams are observing various internal deadlines prior to that important date to ensure a complete and timely release. As we look ahead, OpenStack's election officials will begin accepting self-nominations for the upcoming Project Team Lead roles and four seats on the OpenStack Technical Committee starting 2025-08-06 [2]. The nomination deadline is two weeks later, on 2025-08-20. You are welcome to submit an early nomination [3] now if you anticipate being away during the nomination window. To be a Project Team Lead candidate, you must be an Active Project Contributor—i.e., someone who has contributed to the project you wish to lead in the past 12 months (counted up to 2025-08-20). Any individual member of the OpenInfra Foundation, regardless of contributor status, may propose their candidacy for the OpenStack Technical Committee. To vote in these elections, you must be a member of the OpenInfra Foundation [4] and an active contributor—either through merged contributions to official projects or via nomination by a project’s PTL, liaisons, any Special Interest Group, or the OpenStack Technical Committee [5]. To receive your ballot, please ensure your email address is added in Gerrit and that you've opted in to receive emails from CIVS before 2025-08-20: https://civs1.civs.us/cgi-bin/opt_in.pl In the past week, the TC approved revised milestones for the cross-project goal of removing the use of Eventlet [6]. We still aim to drop Eventlet usage completely in the 2027.2 ("J") release. The "aetos" project now has a canonical service type called "metric-storage" [7]. Several other governance changes are currently under community review. === Weekly Meeting === The last weekly meeting of the OpenStack TC took place [8] on 2025-07-22, with a smaller attendance than usual. We expect this trend to continue through the summer break in the northern hemisphere. Key updates included changes to the Eventlet-removal goal timeline and a deeper look into the prolonged inactivity of the Monasca project team. While volunteers have consistently expressed interest in maintaining the project, it hasn’t met reactivation milestones since its last active cycle (2024.1). However, some improvements have been merged across the team’s repositories. The TC agreed to enforce a more formal and transparent process: projects must explicitly request extensions to inactive status [9], and future documentation will include retirement deadlines that compel TC votes on any extensions. We'll continue discussing the next steps for Monasca through governance proposals and this mailing list. Opendev administrators informed us that they completed the transition off Nodepool, and Debian Trixie images are nearly ready for testing. This is also useful for transitioning the Ceph CI job to Debian to enable faster fixes in the client software. In open discussion, the group revisited the definition of corporate affiliation in the TC charter. A proposal will be made to clarify what affiliation diversity means and how/why it should be disclosed during elections. The next meeting of the OpenStack Technical Committee is today, 2025-07-29. It will be hosted on the #openstack-tc channel on OFTC at 1700 UTC. Please find the meeting's agenda and other details on its wiki page [10]. I hope you'll be able to join us. === Governance Proposals === === Merged === - Make Eventlet removal deadlines more acceptable for operators | https://review.opendev.org/c/openstack/governance/+/952903 - Retire networking-midonet | https://review.opendev.org/c/openstack/governance/+/955364 === Open for review === - Define "affiliation" within the context of the TC | https://review.opendev.org/c/openstack/governance/+/956024 - Add series names to runtimes doc | https://review.opendev.org/c/openstack/governance/+/955810 - Remove Monasca from active project | https://review.opendev.org/c/openstack/governance/+/953671 - os-test-images never releases | https://review.opendev.org/c/openstack/governance/+/954249 - Require declaration of affiliation from TC Candidates | https://review.opendev.org/c/openstack/governance/+/949432 === Upcoming Events === - 2025-08-06: Nominations open for OpenStack elections: https://governance.openstack.org/election/ - 2025-08-20: Nominations close for OpenStack elections - 2025-08-26: OpenInfra Days, Korea: https://2025.openinfradays.kr/ - 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-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] 2026.1 OpenStack Elections: https://governance.openstack.org/election/ [3] Submitting your candidacy: https://governance.openstack.org/election/#how-to-submit-a-candidacy [4] Join the OpenInfra Foundation: https://openinfra.org/join/individual/ [5] Who is an Active Contributor: https://governance.openstack.org/tc/reference/charter.html#voters-for-tc-se… [6] Eventlet removal timeline: https://governance.openstack.org/tc/goals/selected/remove-eventlet.html#com… [7] OpenStack service types: https://specs.openstack.org/openstack/service-types-authority/#service-data [8] TC Meeting IRC Log 2025-07-22: https://meetings.opendev.org/meetings/tc/2025/tc.2025-07-22-17.00.html [9] Emerging and inactive projects: https://governance.openstack.org/tc/reference/emerging-technology-and-inact… [10] TC Meeting Agenda, 2025-07-29: https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Next_Meeting

1 0

[manila] Flamingo Mid Cycle: Aug 6 - 7th
by Carlos Silva 28 Jul '25

28 Jul '25

Hello, Zorillas and interested stackers, The OpenStack Manila's mid cycle event [1] will take place on Aug 6th and 7th, from 14 to 16 UTC. More details on the .ics file [1]. At the event, we will focus on checking on the progress of the deliverables we planned for this cycle, as well as do collaborative review sessions for the features being proposed to speed up the review process. If you have a topic you would like to discuss, please add them to the mid cycle etherpad [2]. [1] https://gist.github.com/silvacarloss/598ad6d311cfe0a588b6b47ea979dff5 [2] https://etherpad.opendev.org/p/manila-flamingo-mid-cycle Looking forward to it, carloss

1 0

[i18n] Sharing CMU Students’ Contributions: Progress on Zanata-to-Weblate Migration
by Ian Y. Choi 28 Jul '25

28 Jul '25

Dear OpenStack Community, Over the past six weeks, Seongsoo and I had the privilege of mentoring a group of four students from Carnegie Mellon University (CMU) [1] as part of our ongoing effort to migrate the OpenStack Internationalization (I18n) platform from Zanata to Weblate. I would like to take this opportunity to highlight the significant and meaningful contributions made by three students, Furqan Saeed, Simon Yu, and Jana Hussien, who recently completed video demos showcasing their work [2] [3]. Project Context As many may know, the I18n SIG has been working to modernize our translation infrastructure by transitioning from Zanata (now unmaintained) to Weblate — an actively developed, open source platform. This project not only ensures the sustainability of our translations, but also offers a valuable learning path for new contributors. Below are the key outcomes achieved by Furqan, Simon and Jana: 1. i18n tools script test codes for Weblate (by Furqan Saeed & Simon Yu) Furqan and Simon focused on bringing robust, production-quality unit testing to the collection of Python scripts and tools responsible for Weblate integration. Furqan’s video [2] demonstrates these efforts. Together, they: Developed a comprehensive suite of ~34 unit tests covering the main Weblate tool files. Used Python’s unittest and mocking strategies to ensure functions behave as expected, even simulating server responses. Noted and addressed gaps in requirements, such as missing library dependencies. Provided clear documentation (README.rst) explaining test infrastructure and file structure. Gained and demonstrated familiarity with OpenStack’s development guidelines, Gerrit workflows, and CI requirements. Their efforts establish a much needed test baseline for future improvements and bring our I18n tooling closer to OpenStack’s best practices. This contribution not only enhances software reliability but also creates a safer, more efficient environment for future contributors. 2. Migration of Zuul infrastructure scripts to Weblate (by Jana Hussien) Jana concentrated on migrating and refactoring the automation scripts that enable daily translation updates in Zuul, shifting from Zanata to Weblate. Her work involved: Analyzing and translating the logic in current scripts to ensure seamless migration, including first-time migration routines for new projects. Developing new scripts to automate creation of Weblate components and upload of translation templates (POT) and PO files; handling language code transformations between platforms. Troubleshooting integration challenges between Weblate’s API/CLI and OpenStack workflows, identifying and overcoming tricky configuration issues related to version control structure. Successfully demonstrating the migration workflow for projects such as trove-dashboard and horizon, with detailed documentation of results. Improving operational resilience by implementing enhanced error handling and summary reporting in the scripts. Discovering and addressing several issues during live testing, and documenting workarounds and plans for future improvements. Jana has also outlined next steps, including integrating these scripts further into the Zuul pipeline, modularizing code, and enhancing public documentation. These contributions represent valuable progress toward a full, sustainable migration to Weblate - benefiting the entire OpenStack community by advancing our translation workflows and broadening global accessibility. On behalf of all mentors (myself, Seongsoo Cho, Goutham Pacha Ravi), I’d like to thank Furqan, Simon, and Jana for their hard work, dedication, and collaborative spirit, and encourage other students and new contributors to get involved. If anyone would like to review their code, documentation, or get involved in this effort, please feel free to reach out or interact directly with their contributions [6-9]! Best regards, Ian Y. Choi (ianychoi) & Seongsoo Cho (seongsoocho) OpenStack I18n SIG & Student Mentors [1] https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack… [2] Video - OpenStack I18n Zanata-to-Weblate Migration: Weblate Tools Unit Test Development (CMU Project Demo) (Furqan), link: https://youtu.be/w966IpBCqeE [3] Video - OpenStack I18n Zanata-to-Weblate Migration: Translation Scripts working on Zuul (CMU Project Demo) (Jana), link: https://youtu.be/RcQweOe-vfo [4] Photo of our kick off meeting: https://photos.app.goo.gl/QhNwBusFZjwvTBzi7 [5] Photos of our final mentoring meeting: Final Mentoring Meeting - https://1drv.ms/f/c/6cc85a64cb418204/EljY3AfrnypGrF6EyDZq83MBDZpLTPt-8VPymj… [6] https://review.opendev.org/c/openstack/i18n/+/953745 (by Furqan, review is welcome) [7] https://review.opendev.org/c/openstack/i18n/+/955982 (by Simon, review is welcome) [8] https://review.opendev.org/c/openstack/i18n/+/955439 (by Jana, working in progress) [9] https://review.opendev.org/c/openstack/trove-dashboard/+/952787 (by Jana, merged)

1 0

[neutron] Bug Deputy Jul 14 - Jul 28
by Jakub Libosvar 28 Jul '25

28 Jul '25

Hi, as I didn’t find the bug deputy report from the last week and confirmed by looking at the IRC meeting logs, I’ve skimmed through the bugs of the last 2 weeks to make sure nothing falls through the cracks. There are a few incomplete bugs that require more info from the reporters in order to find the culprit, seems Brian and Rodolof are on top of it. There is one Critical from today and seems it’s clear what is wrong with it and it seems Yatin is looking at it. Thanks Kuba Critical -------- * tobiko jobs failing while download fedora qcow2 image Edit https://bugs.launchpad.net/neutron/+bug/2118902 Yatin seems to be looking into it Fedora 40 image URL has moved, we need to update the URL to fetch Fedora 41 High —--- * test_subport_delete random failure https://bugs.launchpad.net/neutron/+bug/2117405 Functional test that fails sporadically Assigned to Rodolfo * [tobiko] OVN Metadata agent class failing when using OVN agent https://bugs.launchpad.net/neutron/+bug/2118398 Assigned to Rodolfo Patch proposed: https://review.opendev.org/c/x/tobiko/+/955769 * OVN Neutron agent is being registered as OVN Metadata agent https://bugs.launchpad.net/neutron/+bug/2118876 Rodolfo and Yatin are working on it Patch proposed: https://review.opendev.org/c/openstack/neutron/+/955987 Medium ------- * Horizon shows all prefix lengths when creating subnet from subnet pool https://bugs.launchpad.net/neutron/+bug/2116927 Lajos looked at it as it might be related to the SDK migration, unclear if any fix in Neutron is required * [eventlet-removal] Add N535 hacking check to ban eventlet imports https://bugs.launchpad.net/neutron/+bug/2117373 This is to add the check into Neutron tree but later the check itself was questioned as it might be not working as intended * [neutron-tempest-plugin] Test ``test_create_router_update_external_gateways`` failing https://bugs.launchpad.net/neutron/+bug/2117383 Assigned to Miguel * [unmaintained-only] unknown keyword flow_group_id https://bugs.launchpad.net/neutron/+bug/2117477 Assigned to Bence * [OVN] OVN agents should clean up "Chassis_Private" previous tags https://bugs.launchpad.net/neutron/+bug/2118893 Assigned to Rodolfo Patch proposed: https://review.opendev.org/c/openstack/neutron/+/955998 Low —-- * NotFoundException: 404 error when associating FIP with an unreachable network https://bugs.launchpad.net/neutron/+bug/2118360 Incomplete ---------- * VPN Perfect Forward Secrecy (PFS) is deactivated although configured as active https://bugs.launchpad.net/neutron/+bug/2116723 Rodolfo asked the reporter for more details * Performance Tuning for Nested VXLAN Tunnel in OpenStack (OVS Backend) https://bugs.launchpad.net/neutron/+bug/2116837 Brian asked the reporter for more details * OVN: Intermittent metadata failures for SR-IOV VMs https://bugs.launchpad.net/neutron/+bug/2117078 Rodolfo asked the reporter for more details, the root cause is still unknown * neutron-openvswitch-agent crashes on start https://bugs.launchpad.net/neutron/+bug/2117153 Brian asked the reporter for more details, the root cause is still unknown, happened just once

1 0

Ovn ext ports
by engineer2024 26 Jul '25

26 Jul '25

I have marked a chassis as extport host. But when a sriov port is created, it is being claimed by the node from the controller logs, but it is showing up and down in southbound alternatively,. But when the same node is marked as chassis-gw, the sriov port is showing as up in southbound and stable. What's could be the reason for this? Thanks elinux

1 0

[ops][largescale-sig][scientific-sig] Ops Radio Hour on July 25, 2025
by Ildiko Vancsa 25 Jul '25

25 Jul '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 __July 25th, 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: - OVN Migration +Documentation proposal: https://github.com/mariojmdavid/migrate-to-ovn - (SWIFT) Compliance processes - GPUs - VMware migration - vTPM (live migrations or not?): reboot, start 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 July 25th! Bets Regards, Ildikó [1] https://wiki.openstack.org/wiki/Operations/Meetups

1 1

[PTLs][all] 2026.1 Gazpacho's proposed cycle/release schedule
by Elõd Illés 25 Jul '25

25 Jul '25

Hi, This is just to advertise next cycle's proposed release schedule [1][2]. Feel free to comment on the patch [1] about the timing of milestones, etc. The generated page can also be checked here [2] (though be careful, as this belongs to PS4, so if that is not the latest patch set at the time of looking, then please search for the latest one). [1] https://review.opendev.org/c/openstack/releases/+/954614 [2] https://6b6a75d201a9c42f31a1-68f6595b812925233ee703f28dff66ba.ssl.cf5.rackc… Cheers, Elod Illes irc: elodilles @ #openstack-release

1 0

[Kolla-ansible][epoxy]nova problems at restart
by Franck VEDEL (UGA) 25 Jul '25

25 Jul '25

Hello everyone, I need your help. II will try to explain my problem by providing a lot of information. I have been trying to solve it for 3 days, without success. In May, my old cluster became too small for the 200 students using it, so I started installing a new cluster. Six nodes, three in one data center, three in another. After testing with Bobcat and Caracal (unsatisfactory, with numerous issues, especially with authentication and display in Horizon), I tried Epoxy. I installed everything I needed and tested it. It was a real success. It was very fast in its new configuration, and I thought everything would be ready by September. In May, my old cluster was becoming too small for the 200 students using it, so I started installing a new cluster. 6 nodes, 3 in one data center, 3 in another. After testing with Bobcat and Caracal (unsatisfactory, with numerous issues, especially with authentication and display in Horizon), I tried Epoxy. I installed everything I needed and tested it. It was a real success. It was very fast in its new configuration; I thought everything would be ready by September. At the beginning of July, I was told to shut down everything, due to electrical maintenance in a data center. I shut everything down. 3 days later, I restarted it, and nothing worked anymore. However, it was simply a shutdown/restart of the servers. The problems are with Nova. Here's some information and logs, if you can help me restart the cluster. So Epoxy on Ubuntu 2404. (venv2) user1@ordi1:~/OPENSTACK/INSTALL$ kolla-ansible --version kolla-ansible 20.0.1.dev4 Since nova didn't want to work I did this: (venv2) user1@ordi1:~/OPENSTACK/INSTALL$ kolla-ansible reconfigure -I multinode -t nova ERROR with a task: TASK [nova-cell : Waiting for nova-compute services to register themselves] **************** skipping: [ordi2] skipping: [ordi3] skipping: [ordi4] skipping: [ordi5] skipping: [ordi6] An exception occurred during task execution. To see the full traceback, use -vvv. The error was: json.decoder.JSONDecodeError: Expecting value: line 1 column 1 (char 0) fatal: [ordi1]: FAILED! => {"msg": "Unexpected failure during module execution: Expecting value: line 1 column 1 (char 0)", "stdout": ""} I search with Google and find this (BUG2 in the link): https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack… But I am in 20.0.1.dev4 There is a lot of logs (with nova)….. total 533340 -rw-r--r-- 1 42436 42436 0 juil. 17 06:42 nova-api.log -rw-r--r-- 1 42436 42436 105512247 juil. 17 06:42 nova-api.log.1 -rw-r--r-- 1 42436 42436 2460643 juil. 6 06:40 nova-api.log.2.gz -rw-r--r-- 1 42436 42436 7305818 juil. 5 06:31 nova-api.log.3.gz -rw-r--r-- 1 42436 42436 7234505 juil. 2 06:48 nova-api.log.4.gz -rw-r--r-- 1 42436 42436 2356307 juin 29 06:35 nova-api.log.5.gz -rw-r--r-- 1 42436 42436 7181854 juin 28 06:49 nova-api.log.6.gz -rw-r--r-- 1 42436 42436 56065234 juil. 18 09:06 nova-api-uwsgi.log -rw-r--r-- 1 42436 42436 113689390 juil. 17 06:42 nova-api-uwsgi.log.1 -rw-r--r-- 1 42436 42436 2150056 juil. 6 06:40 nova-api-uwsgi.log.2.gz -rw-r--r-- 1 42436 42436 6393602 juil. 5 06:31 nova-api-uwsgi.log.3.gz -rw-r--r-- 1 42436 42436 6383183 juil. 2 06:48 nova-api-uwsgi.log.4.gz -rw-r--r-- 1 42436 42436 2083376 juin 29 06:35 nova-api-uwsgi.log.5.gz -rw-r--r-- 1 42436 42436 6351824 juin 28 06:49 nova-api-uwsgi.log.6.gz -rw-r--r-- 1 42436 42436 1467596 juil. 18 09:06 nova-compute.log -rw-r--r-- 1 42436 42436 2626598 juil. 18 09:06 nova-conductor.log -rw-r--r-- 1 42436 42436 44883046 juil. 18 06:45 nova-conductor.log.1 -rw-r--r-- 1 42436 42436 7154 juil. 18 08:58 nova-manage.log -rw-r--r-- 1 42436 42436 221050 juil. 16 15:08 nova-metadata.log -rw-r--r-- 1 42436 42436 28094556 juil. 18 09:06 nova-metadata-uwsgi.log -rw-r--r-- 1 42436 42436 74174166 juil. 17 06:42 nova-metadata-uwsgi.log.1 -rw-r--r-- 1 42436 42436 5650339 juil. 5 06:31 nova-metadata-uwsgi.log.2.gz -rw-r--r-- 1 42436 42436 1861983 juin 29 06:35 nova-metadata-uwsgi.log.3.gz -rw-r--r-- 1 42436 42436 5601477 juin 27 06:53 nova-metadata-uwsgi.log.4.gz -rw-r--r-- 1 42436 42436 5640648 juin 21 06:36 nova-metadata-uwsgi.log.5.gz -rw-r--r-- 1 42436 42436 1871248 juin 15 06:43 nova-metadata-uwsgi.log.6.gz -rw-r--r-- 1 42436 42436 111880 juil. 16 15:08 nova-novncproxy.log -rw-r--r-- 1 42436 42436 2668833 juil. 18 09:06 nova-scheduler.log -rw-r--r-- 1 42436 42436 45997165 juil. 18 06:45 nova-scheduler.log.1 -rw-r--r-- 1 42436 42436 0 mai 15 08:47 privsep-helper.log 2 containers have problems: docker ps -a CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES 6231ee0f3c97 quay.io/openstack.kolla/nova-scheduler:2025.1-ubuntu-noble "dumb-init --single-…" 10 minutes ago Exited (1) 5 seconds ago nova_scheduler 57707a9d136e quay.io/openstack.kolla/nova-conductor:2025.1-ubuntu-noble "dumb-init --single-…" 39 hours ago Exited (1) 4 seconds ago nova_conductor Have a look to nova_conductor.log (same thing with nova_scheduler): 2025-07-18 09:08:25.170 7 ERROR nova.scheduler.client.report [-] Failed to initialize placement client (is keystone available?): openstack.exceptions.NotSupported: The placement service for 192.168.100.100:RegionOne exists but does not have any supported versions. 2025-07-18 09:08:25.171 7 ERROR nova.conductor.manager [-] Fatal error initializing placement client: The placement service for 192.168.100.100:RegionOne exists but does not have any supported versions.: openstack.exceptions.NotSupported: The placement service for 192.168.100.100:RegionOne exists but does not have any supported versions. 2025-07-18 09:08:25.172 7 CRITICAL nova [-] Unhandled error: openstack.exceptions.NotSupported: The placement service for 192.168.100.100:RegionOne exists but does not have any supported versions. 2025-07-18 09:08:25.172 7 ERROR nova Traceback (most recent call last): 2025-07-18 09:08:25.172 7 ERROR nova File "/var/lib/kolla/venv/bin/nova-conductor", line 8, in <module> 2025-07-18 09:08:25.172 7 ERROR nova sys.exit(main()) 2025-07-18 09:08:25.172 7 ERROR nova ^^^^^^ 2025-07-18 09:08:25.172 7 ERROR nova File "/var/lib/kolla/venv/lib/python3.12/site-packages/nova/cmd/conductor.py", line 45, in main 2025-07-18 09:08:25.172 7 ERROR nova server = service.Service.create(binary='nova-conductor', 2025-07-18 09:08:25.172 7 ERROR nova ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 2025-07-18 09:08:25.172 7 ERROR nova File "/var/lib/kolla/venv/lib/python3.12/site-packages/nova/service.py", line 256, in create 2025-07-18 09:08:25.172 7 ERROR nova service_obj = cls(host, binary, topic, manager, 2025-07-18 09:08:25.172 7 ERROR nova ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 2025-07-18 09:08:25.172 7 ERROR nova File "/var/lib/kolla/venv/lib/python3.12/site-packages/nova/service.py", line 120, in __init__ 2025-07-18 09:08:25.172 7 ERROR nova self.manager = manager_class(host=self.host, *args, **kwargs) 2025-07-18 09:08:25.172 7 ERROR nova ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 2025-07-18 09:08:25.172 7 ERROR nova File "/var/lib/kolla/venv/lib/python3.12/site-packages/nova/conductor/manager.py", line 124, in __init__ 2025-07-18 09:08:25.172 7 ERROR nova self.compute_task_mgr = ComputeTaskManager() 2025-07-18 09:08:25.172 7 ERROR nova ^^^^^^^^^^^^^^^^^^^^ 2025-07-18 09:08:25.172 7 ERROR nova File "/var/lib/kolla/venv/lib/python3.12/site-packages/nova/conductor/manager.py", line 255, in __init__ 2025-07-18 09:08:25.172 7 ERROR nova self.report_client 2025-07-18 09:08:25.172 7 ERROR nova File "/var/lib/kolla/venv/lib/python3.12/site-packages/nova/conductor/manager.py", line 283, in report_client 2025-07-18 09:08:25.172 7 ERROR nova return report.report_client_singleton() 2025-07-18 09:08:25.172 7 ERROR nova ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 2025-07-18 09:08:25.172 7 ERROR nova File "/var/lib/kolla/venv/lib/python3.12/site-packages/nova/scheduler/client/report.py", line 91, in report_client_singleton 2025-07-18 09:08:25.172 7 ERROR nova PLACEMENTCLIENT = SchedulerReportClient() 2025-07-18 09:08:25.172 7 ERROR nova ^^^^^^^^^^^^^^^^^^^^^^^ 2025-07-18 09:08:25.172 7 ERROR nova File "/var/lib/kolla/venv/lib/python3.12/site-packages/nova/scheduler/client/report.py", line 237, in __init__ 2025-07-18 09:08:25.172 7 ERROR nova self._client = self._create_client() 2025-07-18 09:08:25.172 7 ERROR nova ^^^^^^^^^^^^^^^^^^^^^ 2025-07-18 09:08:25.172 7 ERROR nova File "/var/lib/kolla/venv/lib/python3.12/site-packages/nova/scheduler/client/report.py", line 280, in _create_client 2025-07-18 09:08:25.172 7 ERROR nova client = self._adapter or utils.get_sdk_adapter( 2025-07-18 09:08:25.172 7 ERROR nova ^^^^^^^^^^^^^^^^^^^^^^ 2025-07-18 09:08:25.172 7 ERROR nova File "/var/lib/kolla/venv/lib/python3.12/site-packages/nova/utils.py", line 1035, in get_sdk_adapter 2025-07-18 09:08:25.172 7 ERROR nova return getattr(conn, service_type.replace('-', '_')) 2025-07-18 09:08:25.172 7 ERROR nova ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 2025-07-18 09:08:25.172 7 ERROR nova File "/var/lib/kolla/venv/lib/python3.12/site-packages/openstack/service_description.py", line 88, in __get__ 2025-07-18 09:08:25.172 7 ERROR nova proxy = self._make_proxy(instance) 2025-07-18 09:08:25.172 7 ERROR nova ^^^^^^^^^^^^^^^^^^^^^^^^^^ 2025-07-18 09:08:25.172 7 ERROR nova File "/var/lib/kolla/venv/lib/python3.12/site-packages/openstack/service_description.py", line 290, in _make_proxy 2025-07-18 09:08:25.172 7 ERROR nova raise exceptions.NotSupported( 2025-07-18 09:08:25.172 7 ERROR nova openstack.exceptions.NotSupported: The placement service for 192.168.100.100:RegionOne exists but does not have any supported versions. 2025-07-18 09:08:25.172 7 ERROR nova Another thing is strange: Autre point bizarre: tail -f /var/log/kolla/placement/placement-api-uwsgi.log --- no python application found, check your startup logs for errors --- [pid: 1092|app: -1|req: -1/307186] 192.168.100.4 () {22 vars in 215 bytes} [Fri Jul 18 09:11:28 2025] GET / => generated 21 bytes in 0 msecs (HTTP/1.0 500) 3 headers in 102 bytes (0 switches on core 0) What can I do ? Can you help me to find a solution to restart my Openstack ? Thanks a lot if you can. Franck

3 8

[neutron]instances can see traffic of others
by Nguyễn Hữu Khôi 24 Jul '25

24 Jul '25

Hello, I have some instances in the same vlan and compute node. They can see traffic from another instance which looks like port mirror. I can workaround via anti affinity rules but is there any solution for this problem? On vmware we can turn off or on promiscuous mode on the network port group. Thank you. Regards Nguyen Huu Khoi

2 6

[kolla][barbican] How to securely manage OpenStack service passwords with Castellan?
by elnaz cl 24 Jul '25

24 Jul '25

Hi all, I have deployed OpenStack using Kolla Ansible. By default, service passwords (e.g., for MySQL, Keystone, etc.) are stored in clear text inside configuration files rendered by Kolla (such as nova.conf, keystone.conf, etc.). I'm looking for a more secure approach to avoid exposing these secrets. Specifically, is there a way to integrate Barbican and Castellan with Kolla-based deployments, so that secrets can be securely loaded at runtime using oslo.config (e.g., using {{ secret:UUID }})? If this is not natively supported, are there any best practices or workarounds for handling this securely? Thanks in advance for any guidance. Best, [Your Name]

1 0

[neutron] metadata-agents work but are not alive
by Eugen Block 23 Jul '25

23 Jul '25

2 4

Neutron dhcp
by engineer2024 23 Jul '25

23 Jul '25

Hi Folks, In a neutron DHCP network, the route to the link local metadata ip from a VM, is thru the ip set by the neutron dhcp agent's static route option for that subnet. This is the same IP as that of the qdhcp namespace's tap interface. Can we choose a specific ip from this subnet and pass it to neutron to use the same when assigning the ip in qdhcp ns and as a static route option to link local ?

2 1

[Ironic][Plugins] networking-baremetal vs networking-generic-switch
by Joao Antonio 22 Jul '25

22 Jul '25

Hello, team! What is the difference between *networking-generic-switch* and *networking-baremetal* in terms of l*ocal_link_information*? The networking-generic-switch README file is explicit about local_link_information. Does networking-baremetal also handle local_link_information? -- Joao

2 1

[cinder] Disable Availability Zone
by Kees Meijs | Nefos 22 Jul '25

22 Jul '25

Hello Stackers, For legacy purposes, we've got an Availability Zone running that's not to be used for new workload any more. Within Nova one could simply disable Compute Nodes (and that's what we did) ensuring no Compute Instances get scheduled. But, how about Cinder? How can we keep current workload running within a certain AZ, but ensure no new workload gets accepted? Thanks! Cheers, Kees

1 0

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

22 Jul '25

Hello Stackers, We're ten weeks away from the coordinated release of OpenStack 2025.2 ("Flamingo") [1]. The feature freeze date for this release is in five weeks (2025-08-28). In the past week, the OpenStack Technical Committee did not merge any new governance changes, though a few are currently under community review. === Weekly Meeting === The last weekly meeting of the OpenStack Technical Committee took place on 2025-07-15 over IRC [2]. The TC caught up on a backlog of action items, starting with progress on the community goal to drop the use of eventlet [3]. We discussed the activity within the Monasca project team and have reached out to the PTL and core reviewers to talk about its future. The rest of the meeting focused on the maintenance of the "service-types-authority" repository. While some suggested involving the openstacksdk-core team in its maintenance, others opined that the repo should remain under TC oversight due to its governance significance—since changes affect how services are named and recognized across the ecosystem. For now, we have renewed our commitment to reviewing and merging change proposals more actively. A late tangent about the First Contact SIG’s dormancy prompted an idea to review SIG activity at the upcoming PTG in October. The next meeting of the OpenStack TC is today, 2025-07-22, at 1700 UTC. This meeting will be hosted over IRC on the #openstack-tc channel on OFTC. The agenda has been added to the meeting's wiki page [4]. I hope you'll be able to join us there. Any community member is welcome to edit the wiki page and propose new topics. === Governance Proposals === ==== Open for review ==== - os-test-images never releases | https://review.opendev.org/c/openstack/governance/+/954249 - Retire networking-midonet | https://review.opendev.org/c/openstack/governance/+/955364 - 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 === Upcoming Events === - 2025-07-26: OpenInfra Days, Vietnam: https://www.vietopeninfra.org/void2025 - 2025-08-06: Nominations open for OpenStack elections: https://governance.openstack.org/election/ - 2025-08-26: OpenInfra Days, Korea: https://2025.openinfradays.kr/ - 2025-08-29: Colombia OpenInfra User Group Meetup: https://www.meetup.com/colombia-openinfra-user-group/events/307096751/ - 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] TC Meeting IRC Log 2025-07-15: https://meetings.opendev.org/meetings/tc/2025/tc.2025-07-15-17.00.html [3] Eventlet removal goal timeline changes: https://review.opendev.org/c/openstack/governance/+/952903 [4] TC Meeting Agenda, 2025-07-22: https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Next_Meeting

1 0

Instance Freeze During Snapshot in OpenStack 2024.1 with Ceph Octopus
by mohammad kokabi 21 Jul '25

21 Jul '25

Hello, I hope this message finds you well. I am currently using OpenStack version 2024.1, with Ceph Octopus as the backend storage. The configuration is as follows: Glance is configured to use the "images" pool on Ceph. The virtual machine disks are stored on the "vms" pool. When I attempt to create a snapshot of a running instance, the instance appears to freeze for a few seconds, during which it loses network connectivity (e.g., I cannot ping it). This behavior is unexpected, as I understand that snapshot operations, especially with Ceph backend, should not significantly interrupt the instance's runtime. Could you please advise what might be causing this issue? Are there any known limitations, configurations, or best practices I should be aware of regarding snapshot behavior with Ceph in this version of OpenStack? Looking forward to your insights. Best regards,

2 1

RE: Create image error
by berndbausch＠gmail.com 21 Jul '25

21 Jul '25

Violating limits imposed by the operator should lead to a useful error message rather than an HTTP 5xx error. In any case, there should have been a message in the Glance API log. Perhaps you are using a prerelease version of OpenStack? When you get Devstack from the Git, you may want to specify the version; otherwise, you obtain software that is currently under development. For example, the following gets you the first version released this year (Epoxy): git clone https://opendev.org/openstack/devstack -b stable/2025.1 ------------------------------------------------------------------------------------------------------------------- From: BEDDA Fadhel <fadhel.bedda(a)gmail.com> Sent: Saturday, May 31, 2025 6:00 PM To: berndbausch(a)gmail.com Subject: Re: Create image error Hello, I was able to work around the problem by disabling the limits in the file: /etc/glance/glance-api.conf False instead of True Thanks Le sam. 31 mai 2025 à 09:55, <mailto:berndbausch@gmail.com> a écrit : My guess is that the image service is down. To check its status: systemctl status devstack@g-api Also check the image service log: journalctl -e -u devstack@g-api ------------------------------------------------------------------------ From: BEDDA Fadhel <mailto:fadhel.bedda@gmail.com> Sent: Saturday, May 31, 2025 3:08 PM To: mailto:openstack-discuss@lists.openstack.org Subject: Create image error Hi everyone, I installed OpenStack (DevStack). At first, I was able to create three images (Ubuntu, Debian, and Windows) in addition to the Cirros image. When I tried to add another image, everything got stuck. I couldn't add any images, and I got the infamous error 550. HttpException: 502: Server Error for url:

1 0

[tacker] Skip today's IRC meeting
by Yasufumi Ogawa 21 Jul '25

21 Jul '25

Hi Tacker team, Sorry for the late notice. Due to a holiday in Japan and most of us will not join, I would like to skip today's IRC meeting. Thanks, Yasufumi

1 0

[kolla-ansible][proxysql] "Wait for backup proxysql container to start" fails
by Bursztynowski Dariusz 20 Jul '25

20 Jul '25

Hello OpenStack community, Installing Kolla-ansible OpenStack 2025.1, I've met a problem with proxysql which does not start (in task [loadbalancer : Wait for backup proxysql to start]) because of unsupported system page size: sudo cat /var/log/kolla/proxysql/proxysql.log <jemalloc>: Unsupported system page size <jemalloc>: Error in malloc(): out of memory I'm working with aarch64 CPU (Raspberry Pi 5 cluster, instructive tool for educational purposes). I have posted the bug here including more detailed description: https://bugs.launchpad.net/kolla-ansible/+bug/2117309 . What is interesting, version 2023.1 works just fine on the same HW/OS platform. I would be grateful for any suggestions on how to resolve this. Best, Dariusz Bursztynowski

1 1

[Nova] Unable to fetch CPU/RAM allocation ratios via /os-hypervisors API (Nova API v2.91 vs v2.1 support)
by Thamanna Farhath 19 Jul '25

19 Jul '25

Hello OpenStack community, I'm working with OpenStack (2023.1 kolla ansible) Nova and using the /os-hypervisors API to gather hypervisor information. I noticed that the CPU and RAM allocation ratios (which are shown in the Horizon dashboard) are not included in the response from: GET /os-hypervisors GET /os-hypervisors/{id} We're currently using Nova API version 2.91, but I see that the /os-hypervisors API appears to support only up to version 2.1, I’d like to clarify the following points: Is it expected behavior that the /os-hypervisors API does not return CPU and RAM allocation ratios? Is there any API endpoint that exposes these ratios programmatically? As we are using Nova API version 2.91, but /os-hypervisors seems limited to v2.1, is this a known limitation or design choice? If the only source of truth is the nova.conf configuration file (e.g., cpu_allocation_ratio, ram_allocation_ratio), is there any plan to expose this via API in future releases? It would be helpful to know if this is something we should work around by manually collecting config values, or if there's a more appropriate method in modern Nova setups. 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

[mariadb][keystone][blazar] Deadlock error on Galera cluster
by Winicius Allan 18 Jul '25

18 Jul '25

Hi community o/ Suddenly, I noticed that the login on the dashboard wasn't working, so I checked the keystone logs. I saw some entries like that: 2025-07-10 00:53:45.120 23 ERROR sqlalchemy.pool.impl.QueuePool oslo_db.exception.DBDeadlock: (pymysql.err.OperationalError) (1205, 'Lock wait timeout exceeded; try restarting transaction') Nova-conductor was also showing messages like these. At the same time, blazer-manager was logging after every _process_event calling: ERROR sqlalchemy.exc.TimeoutError: QueuePool limit of size 1 overflow 50 reached, connection timed out, timeout 30.00 I do not know if it's related to the _process_event method that batches events concurrently[1], and the DB was locked. Well... I increased the max_pool_size from 1 to 2 on blazar-manager, and that message stops showing. Does anyone know what can cause this deadlock generally? I'd like to ask another question: I have three controllers in my environment. Why do controllers with no active VIP address bind connections on the MySQL port, for example: tcp ESTAB 0 0 10.0.0.105:3306 10.0.0.107:50642 users:(("mariadbd",pid=977010,fd=1089)) [1] https://github.com/openstack/blazar/blob/stable/2024.1/blazar/manager/servi… Best regards.

3 5

[ops] Very basic newby questions
by Leroy Tennison 17 Jul '25

17 Jul '25

I am looking for a solution to automatically move (upon request) running VMs from one hypervisor to another. The current hypervisors are KVM/QEMU. Just looking at the documentation I am becoming overwhelmed. Questions (A URL which directly addresses the question is quite acceptable): Does OpenStack work with existing hypervisors or would existing hypervisors have to be "converted" (somehow) to OpenStack? If it can be used with existing hypervisors, is there a how-to for this specific task (I understand that OpenStack can do many things). If OpenStack can't be used with existing hypervisors, are you aware of solutions for this need? I have looked at ProxMox but it appears to want centralized storage and very fast networks which doesn't match the environment. Thank you for your help.

5 10

[neutron] Drivers meeting canceled Friday, July 18th and 25th
by Brian Haley 17 Jul '25

17 Jul '25

Hello Neutrinos: As discussed in our weekly meeting, I am going to cancel the next two Drivers meetings as there is no agenda and I am on PTO. Just a reminder there are still open specs that need review, list is at [0]. Have a nice weekend/week! -Brian [0] https://review.opendev.org/q/status:open+project:openstack/neutron-specs

1 0

[ops][api][all] What are we going to do about pastedeploy usage?
by Stephen Finucane 17 Jul '25

17 Jul '25

oslo.service is going through a lot of churn right now as part of the eventlet migration. We recently noticed that some unrelated WSGI routing code had been inadvertently deprecated, and moved to undeprecate this [1]. In the long-term, however, this code doesn't really belong in oslo.service and should be moved elsewhere. I took a stab at bootstrapping an oslo.wsgi package, and after some hacking I arrived at a dependencies list containing the following: * Paste [2] * PasteDeploy [3] * Routes [4] * WebOb [5] As some of you might know, all of these packages are minimally maintained bordering on unmaintained. I'm not entirely sure we want to want to bootstrap a new project using these libraries as opposed to migrating off of them. My question is this: how important is the pastedeploy framework and the paste.ini files nowadays, particularly for deployers? While their use is relatively consistent across projects (see below), not every service uses them and for those that don't, I personally haven't heard complaints about their absence. Rather than migrating the pastedeploy stuff elsewhere, would it make more sense for affected projects to simply define a static set of middleware (with some config knobs for those we want to be able to enable/disable) and call it a day? Cheers, Stephen PS: This topic came up about 18 months ago [6], but we don't appear to have reached a conclusion. Thus my bringing it up again. [1] https://review.opendev.org/c/openstack/oslo.service/+/954055 [2] https://pypi.org/project/Paste/#history [3] https://pypi.org/project/PasteDeploy/#history [4] https://pypi.org/project/Routes/#history [5] https://pypi.org/project/WebOb/#history [6] https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack… --- fwict, the following services all rely on this combo to build their own frameworks, with Nova most likely the progenitor in each case (I'm guessing) * Nova * Barbican * Cinder * Designate * Freezer * Glance * Heat * Manila * Monasca * Neutron * Swift * Trove * Vitrage * Watcher The following services do *not* use these libraries: * Cyborg (pecan) * Ironic (pecan) * Keystone (Flask + Flask-RESTful, with some webob) * Magnum (pecan) * Masakari (homegrown framework using webob) * Zaqar (falcon) * Zun (Flask)

3 2

[Kolla] Looking for a Support Provider
by Buddhika S. Godakuru - University of Kelaniya 17 Jul '25

17 Jul '25

Hi All, We are a University in Sri Lanka, and we have a small Openstack (2023.1) deployment using Kayobe. The on-prem cloud is currently operational, but currently there is only one member who has the idea about the design, and implementation of hardware/OS/configuration/network setup. So the management is trying to find an additional entity who can support in an emergency, as well as to avoid being dependant on a single person. Are there any person/institute/person who can support our setup (not day to day activities) in case of service/hardware failure, preferably within Sri Lanka. Thank you -- බුද්ධික සංජීව ගොඩාකුරු Buddhika Sanjeewa Godakuru Systems Analyst/Programmer Information and Communication Technology Centre (ICTC) University of Kelaniya, Sri Lanka, Kelaniya, Sri Lanka. -- **** *University of Kelaniya, Sri Lanka, accepts no liability for the content of this email or for the consequences of any actions taken on the basis of the information provided unless that information is subsequently confirmed in writing. * *If you are not the intended recipient, this email and/or any information it contains should not be copied, disclosed, retained or used by you or any other party, and the email and all its contents should be promptly deleted fully, and the sender informed. * ** ** *E-mail transmissions cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete. * ****

2 1

Re: [cinder] How to retype while maintaining volume usage
by Yuta Kambe (Fujitsu) 16 Jul '25

16 Jul '25

Hi Eugen, Thank you for your reply. I've confirmed that 'rbd sparsify' can increase available space. However, I believe there's room for improvement in the retype implementation. Currently, retyping between Ceph backends causes zero-filling, which unnecessarily consumes time and storage space. This is likely to happen frequently, for example, with retypes between Ceph's HDD and SSD backends, and the Ceph administrator would need to run 'rbd sparsify' frequently. Are there any improvements to the retype implementation being considered in the community? I would also appreciate hearing your opinion on the need for improvement. Best regards,

4 11

[horizon] Cancel weekly meetings on 2025-07-23 and 2025-07-30
by Tatiana Ovchinnikova 16 Jul '25

16 Jul '25

Hello team, I am cancelling the two upcoming weekly meetings since about a half of the members are on PTO. See you all in three weeks, August 6th! With kind regards, Tatiana

1 0

[publiccloud-sig] Chairing Public Cloud SIG
by Kees Meijs | Nefos 16 Jul '25

16 Jul '25

Hi all, Recently Felix Kronlage-Dammers asked for someone to take over chairing the bi-weekly Public Cloud SIG. After giving it some thought, I proposed to continue his legacy from the next round and on. Unless someone would object, I'll be sending out meeting invitations from here on. 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.

3 2

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