- 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 02 Aug '25

02 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 01 Aug '25

01 Aug '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