June 2025 - openstack-discuss - lists.openstack.org

Help with vGPU's using an NV L4 card on U24.04 (6.8)
by Tyler Wilson 25 Jun '25

25 Jun '25

Hello All, I'm trying to get vGPU's to work with openstack and I believe I am almost there, however I can't seem to get them to register to placement. Here is what I have so far OS: Ubuntu 24.04 Kernel: 6.8.0-62-generic Nvidia GRID Version: 570.158.02-570.158.01-573.39 Openstack Deployment: Kolla w/ Docker Openstack Version: 2025.1 I have the SRIOV devices enabled with the systemd service, and can see the vgpu types; # cat /sys/bus/pci/devices/0000:25:00.0/virtfn0/nvidia/creatable_vgpu_types ID : vGPU Name 908 : NVIDIA L4-1B 909 : NVIDIA L4-2B 910 : NVIDIA L4-1Q 911 : NVIDIA L4-2Q 912 : NVIDIA L4-3Q 913 : NVIDIA L4-4Q 914 : NVIDIA L4-6Q 915 : NVIDIA L4-8Q 916 : NVIDIA L4-12Q 917 : NVIDIA L4-24Q 918 : NVIDIA L4-1A 919 : NVIDIA L4-2A 920 : NVIDIA L4-3A 921 : NVIDIA L4-4A 922 : NVIDIA L4-6A 923 : NVIDIA L4-8A 924 : NVIDIA L4-12A 925 : NVIDIA L4-24A My kolla node nova custom config (for nova-compute) is [DEFAULT] debug = true verbose = true [devices] enabled_mdev_types = nvidia-918 [mdev_nvidia-918] max_instances = 8 [libvirt] live_migration_downtime = 500000 live_migration_downtime_steps = 3 live_migration_downtime_delay = 3 I've also created flavors, classes, and traits with; openstack flavor create l4-1a --ram 8192 --disk 40 --vcpus 4 openstack flavor set l4-1a --property "resources:VGPU=1" --property "trait:CUSTOM_NVIDIA_918=required" openstack resource class create CUSTOM_NVIDIA_918 openstack trait create CUSTOM_NVIDIA_918 However I can't seem to get placement to show any vGPU's or any of the traits I registered: This just has an empty line # openstack allocation candidate list --resource VGPU=1 and this will just show the standard vCPU/Memory/Disk # openstack resource provider inventory list <Host UUID> Have I missed a step somewhere, do I need to prepare the devices further before nova can pick them up? Thanks for any and all help!

2 1

[largescale-sig] Next meeting: June 25, 14utc
by Thierry Carrez 25 Jun '25

25 Jun '25

Hi everyone, The Large Scale SIG will be meeting this Wednesday in #openstack-operators on OFTC IRC at 14UTC. You can doublecheck how that UTC time translates locally at: https://www.timeanddate.com/worldclock/fixedtime.html?iso=20250625T14 Feel free to add topics to the agenda: https://etherpad.opendev.org/p/large-scale-sig-meeting Regards, -- Thierry Carrez

2 1

[neutron] [openvswitch] Outage problem while upgrading openvswitch
by İzzettin Erdem 25 Jun '25

25 Jun '25

Hello, We have a kolla-ansible yoga environment with 9 controller nodes and more than 1000 compute nodes. When I upgrade neutron and openvswitch to a newer version (doesn't matter which, in my case Antelope) access to all virtual machines is lost, but if there are existing ping flows, new ones are not created. This continues until openvswitch deploy is completed, i.e. neutron_openvswitch restart. In some cases, the access outage can be prolonged. When I send an upgrade to neutron alone, I don't experience any outage. How can I prevent this, is there a way to send a hot-upgrade to neutron&openvswitch without any outage? Or is it normal to have an outage?

2 1

[neutron] Disable fullstack CI job
by Rodolfo Alonso Hernandez 25 Jun '25

25 Jun '25

Hello Neutrinos: As commented yesterday in the Neutron meeting [1], the "fullstack" CI is blocking the eventlet removal. This CI FW is also blocking the SDK migration [2]. The refactor of this CI is now not possible due to time constraints. Because of this, we are going to disable it and migrate the tests implemented to other FWs, if possible. The coverage of this CI is important but limited. The advantage of this FW is the possibility of, for example, restarting services or agents; this is something achieved by other FWs like "tobiko". Another advantage is the possibility of testing with different configurations, but that could also be achieved by using the same CI job with different static configurations; it is also possible to change the API configuration and restart it using "whitebox-neutron-tempest-plugin". I've created a bug to track these efforts [3]. In the next few hours I'll send a patch to remove the "fullstack" FW from our CI. Regards. [1] https://meetings.opendev.org/meetings/networking/2025/networking.2025-06-24… [2]https://review.opendev.org/c/openstack/neutron/+/947851 [3]https://bugs.launchpad.net/neutron/+bug/2115327

1 0

[qa] Devstack gate is blocked, avoid recheck until fix is merged
by Ghanshyam Maan 24 Jun '25

24 Jun '25

Hi All, Devstack master gate is blocked due to swift-dsvm-functional failure. Tim has fix up for review [1], please do not recheck until that is merged. [1] https://review.opendev.org/c/openstack/swift/+/953234 -gmann

1 1

[openstack][octavia]Resize a Load Balancer
by Nguyễn Hữu Khôi 24 Jun '25

24 Jun '25

Hello. I see that patch https://review.opendev.org/c/openstack/octavia/+/890215 Could I ask why we cannot merge it? Nguyen Huu Khoi

2 3

Problems with the Placement service
by Ron Gage 24 Jun '25

24 Jun '25

5 7

[ironic]SSH login failure to baremetal instance deployed by ironic
by Junya Noguchi (Fujitsu) 24 Jun '25

24 Jun '25

To whom it may concern I failed to SSH into a baremetal instance deployed by Ironic. I deployed the baremetal instance using an OS image created for Ironic by Diskimage-builder. When I tried to SSH into the instance, the connection was refused due to a "Permission denied" error. [aaaaaaaa@localhost ~]$ ssh -i .ssh/key.pem cloud-user(a)xxx.xxx.xxx.xxx cloud-user(a)xxx.xxx.xxx.xxx's password: Permission denied, please try again. cloud-user(a)xxx.xxx.xxx.xxx's password: Permission denied, please try again. cloud-user(a)xxx.xxx.xxx.xxx's password: cloud-user(a)xxx.xxx.xxx.xxx: Permission denied (publickey,gssapi-keyex,gssapi-with-mic,password). [aaaaaaaa@localhost ~]$ When I created a virtual machine (VM) instance using the same image, I was able to successfully SSH into it using the same steps. [aaaaaaaa@localhost ~]$ ssh -i .ssh/key.pem cloud-user(a)yyy.yyy.yyy.yyy Last login: Fri Jun 6 07:41:42 2025 from yyy.yyy.yyy.yyy [cloud-user@vm_instance ~]$ To build the OS image, we used the following commands from the ironic-python-agent-builder documentation: $ disk-image-create rocky-container vm dhcp-all-interfaces block-device-efi openssh-server cloud-init growroot -o rocky9.5_ironic_x86 $ openstack image create Rocky-9.5_x86_baremetal --file rocky9.5_ironic_x86.qcow2 --disk-format qcow2 --property architecture=x86_64 --container-format bare In the past, I have successfully SSH login into baremetal instances deployed with OS images created in this way. https://docs.openstack.org/ironic/latest/user/creating-images.html#disk-ima… SSH login succeeds for VM instances but fails for bare metal instances, even though the same OS image is used. If you know the reason why this happens, please let me know. Best regards, Junya Noguchi

2 1

Custom Role Configuration for Admin Activities in OpenStack
by Thamanna Farhath 24 Jun '25

24 Jun '25

Hi Team, As part of enhancing our OpenStack RBAC policy management, we are in the process of setting up custom roles for various admin-related activities. Custom Roles Used: admin_instance_read,admin_volume_read,admin_network_read,admin_glance_read Policy Customizations: # Compute - List all instances across tenants "os_compute_api:servers:index:get_all_tenants": "rule:context_is_admin or role:admin_instance_read" "os_compute_api:servers:detail:get_all_tenants": "rule:context_is_admin or role:admin_instance_read" # Network - Get networks (shared/external/own project) "get_network": "(rule:admin_only) or (role:reader and project_id:%(project_id)s) or rule:shared or rule:external or rule:context_is_advsvc or role:admin_network_read" # Volume - List all volumes and snapshots across projects "volume:get_all": "rule:xena_system_admin_or_project_reader or role:admin_volume_read" "volume:get_all_snapshots": "rule:xena_system_admin_or_project_reader or role:admin_volume_read" # Image - List all images including shared/community/public "get_image": "role:admin or (role:reader and project_id:%(project_id)s) or project_id:%(member_id)s or 'community':%(visibility)s or 'public':%(visibility)s or 'shared':%(visibility)s or role:admin_glance_read" "get_images": "role:admin or (role:reader and project_id:%(project_id)s) or role:admin_glance_read" Issue: Despite the above configurations, listing all instances, images, volumes, and networks across all projects still only works for the admin role. The custom roles (e.g., admin_instance_read, etc.) are not taking effect for cross-project visibility as expected. Request: I would appreciate any suggestions or insights on: Whether additional policy bindings or role scopes are required. If any service-specific constraints might be overriding the custom roles. Any known limitations regarding get_all_tenants behavior with custom roles. Thanks & Regards Thamanna Farhath N Associate engineer - R&D Zybisys IT consulting 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."

5 17

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

23 Jun '25

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

3 10

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

23 Jun '25

Hello Stackers, We're fourteen weeks away from the coordinated 2025.2 "Flamingo" release of OpenStack [1], and Milestone-2 for this release is on 2025-07-03. In the past week, the Call for Papers for the upcoming OpenInfra Summit in Paris-Saclay ended; however, the deadline to propose Forum sessions and Project Updates sessions is 2025-07-08 at 23:59 PST [2]. This time at the summit, there's also a "New Contributor Showcase" inviting presentations on projects that leverage or support open infrastructure. Whether it’s your first contribution, an open source tool, or a collaboration with a community, we want to hear about it, so please consider applying [3]. In the past week, the OpenStack Technical Committee did not merge any new governance changes. A few change proposals are open for the community's input. OpenDev Infra administrators and OpenStack's Release Management team have posted several changes to begin enforcing the Developer Certificate of Origin in lieu of the Contributor License Agreement from July 1, 2025 [4]. If you haven't already begun using "git commit -s" to sign off your commits in adherence to the DCO, please do so. As a reminder, from July 1st, OpenDev's Gerrit system (https://review.opendev.org) will reject any changes that do not include a "Signed-off-by" line in the commit message. Simultaneously, the existing CLAs will no longer be available for new contributors to sign. === Weekly Meeting === The OpenStack Technical Committee met on OFTC's #openstack-tc channel on 2025-06-17 [5]. The team confirmed plans to transition to DCO (Developer Certificate of Origin) by July 1st, approving updates to the contributor guide and discussing the ongoing process of integrating DCO across tools and translations. We then focused on improving the contributor experience, with analyses of review metrics being shared with various project teams like Nova and Cinder through weekly IRC meetings. This data collection aims to identify pain points and best practices to inform future strategies. We plan to drive collective attention to this effort during the PTG in October. We also discussed the level of activity in the Cyborg project. We have had issues contacting the core maintainers to get some critical fixes merged, and the TC agreed to begin the process to mark the project "inactive." This decision aligns with the upcoming M-2 release deadline. The discussion also prompted a health check on several project teams. We'll be discussing this in further detail on proposals directly on Gerrit, or in a future weekly meeting. OpenDev Infra administrators completed a transition from Nodepool to Zuul-launcher and pleasantly have not seen any negative impact on the CI. During an Open Discussion, concerns were raised about the timeline specified by the Eventlet Removal TC goal [6]. Nova maintainers, in particular, expressed the need for more time to ensure a stable transition to threading and adequate operator testing, suggesting a revised target of 2028.1 for full Eventlet removal, a point that will be further debated on the mailing list [7] and a Gerrit proposal [8]. The next meeting of the OpenStack Technical Committee is on 2025-06-24. It will be hosted over IRC in OFTC's #openstack-tc channel at 1700 UTC. Please find the agenda and other details on the meeting's wiki page [9]. I hope you'll be able to join us. === Governance Proposals === ==== Open for review ==== - Require declaration of affiliation from TC Candidates | https://review.opendev.org/c/openstack/governance/+/949432 - Make Eventlet removal deadlines more acceptable for operators | https://review.opendev.org/c/openstack/governance/+/952903 - Mark Cyborg inactive | https://review.opendev.org/c/openstack/governance/+/952798 === Upcoming Events === - 2025-06-28: OpenInfra+Cloud Native Day, Vietnam: https://www.vietopeninfra.org/void2025 - 2025-07-03: OpenStack's 15th Birthday, Colombia User Group: https://www.meetup.com/colombia-openinfra-user-group/events/308383244 - 2025-07-08: OpenInfra Board meeting: https://board.openinfra.org/ - 2025-07-19: OpenInfra Days, Indonesia: https://2025.openinfra.id/ Thank you very much for reading! On behalf of the OpenStack TC, Goutham Pacha Ravi (gouthamr) OpenStack TC Chair

1 1

[neutron] Neutron CI meeting cancelled for today
by Yatin Karel 23 Jun '25

23 Jun '25

Hello Neutron Team !! Sorry for the last minute change as I got it conflicting with an internal meeting. We have some known intermittent issues as mentioned in https://etherpad.opendev.org/p/neutron-ci-meetings#L83. Will report the issues for those tomorrow. -- Thanks and Regards Yatin Karel

1 0

[horizon] Change option to delete volume when deleting instance
by Winicius Allan 23 Jun '25

23 Jun '25

Hello folks, Is there any option to change the default value to delete the volume when deleting the instance on Horizon? In the configuration reference[1], I only found this topic, but nothing about volume deletion [1] https://docs.openstack.org/horizon/latest/configuration/settings.html#launc… Best regards.

2 1

[neutron] Bug deputy report for week 25 of 2025 (June 16th)
by Miguel Lavalle 22 Jun '25

22 Jun '25

I was the Neutron bug deputy last week. Following is a brief summary of the reported bugs: High bugs -------------- https://bugs.launchpad.net/neutron/+bug/2114732 grenade-skip-level-always job fails with: Security Group None cannot perform precommit_delete due to Callback. No owner https://bugs.launchpad.net/neutron/+bug/2115026 test_direct_route_for_address_scope and test_fip_connection_for_address_scope Functional test randomly fails. Assignee Yatin Karel. Proposed fix https://review.opendev.org/c/openstack/neutron/+/952958 Medium ---------- https://bugs.launchpad.net/neutron/+bug/2114819 "tag" plugin is not case sensitive. Assignee Rodolfo Alonso. Proposed fix https://review.opendev.org/c/openstack/neutron/+/952819 https://bugs.launchpad.net/neutron/+bug/2114919 dhcp_ready_on_ports() + fwaas might fail due to open transaction. Assignee Sebastian Lohff. Proposed fix https://review.opendev.org/c/openstack/neutron-fwaas/+/952852 merged https://bugs.launchpad.net/neutron/+bug/2115053 conntrack flow created for stateless SG rule. No owner Low ----- https://bugs.launchpad.net/neutron/+bug/2114832 [FT] ``test_agent_show_real_heartbeat_timestamp`` should check the timestamp in UTC timezone. Assignee Rodolfo Alonso. https://bugs.launchpad.net/neutron/+bug/2114909 [FT] Random errors in ``test_create_bridges`` . Assignee Rodolfo Alonso. Proposed fix https://review.opendev.org/c/openstack/neutron/+/952828 merged

1 0

Inquiry on Integrating Ansible with Vendor-Specific Cinder Driver Code
by Sumit Gupta 21 Jun '25

21 Jun '25

Hello Moderators, We maintain a substantial body of open-source Ansible code (certified by Red Hat as a collection) for IBM Storage Virtualize, which we believe could directly benefit the Cinder driver roadmap. I’d like to understand whether it is technically and architecturally acceptable to invoke Ansible scripts from within a vendor-specific Cinder driver. Specifically: * Are there any guidelines or constraints on integrating external automation tools (like Ansible) within a Cinder driver implementation? * Is there any official documentation on the acceptance of such cross-language or framework integrations (e.g., calling Ansible from Python)? Your guidance would be greatly appreciated to ensure any contributions align with community standards and best practices. Thank you! Sumit K Gupta sumit.gupta16(a)ibm.com Senior Storage Leader, IBM

2 1

[eventlet-removal]When to drop eventlet support
by Balazs Gibizer 19 Jun '25

19 Jun '25

Hi Stackers! I would like to sync about the planned timeline of dropping eventlet support from OpenStack / Oslo. Nova definitely needs at least the full 2026.1 cycle to have a chance to transform the nova-compute service. But this plan already feels stretched based on the progress in the current cycle. So being conservative means we need the 2026.2 cycle as a buffer. Nova would like to keep a release where we support both eventlet and threading in parallel. So that operators can do the switching from eventlet to threading outside of the upgrade procedure. (This was an explicit request from them during the PTG). So 2026.2 could be that version where nova fully supports both concurrency mode, while eventlet can be marked deprecated. Then the 2027.1 release could be the first release dropping eventlet. However we need to align with the SLURP upgrade as well. 2026.1 is a SLURP. But in that release Nova might not be ready to have all services running in threading mode. So the 2026.1 - 2027.1 SLURP upgrade would force the operators to change the concurrency mode during the upgrade itself. I see two ways forward: * A) We say that operators who want to do the concurrency mode change outside of an upgrade could not skip the 2026.2 release, i.e. they cannot do SLURP directly from 2026.1. to 2027.1. * B) We keep supporting the eventlet mode in the 2027.1 release as well and only dropping support in 2028.1. What do you think? Cheers gibi

10 22

[Cinder] SystemReader & all_tenants filter issue
by skryhin＠godaddy.com 19 Jun '25

19 Jun '25

Hey Cinder team, We're running into a problem where our SystemReader role can't use the all_tenants filter when listing Cinder volumes (e.g., via `openstack volume list --all-projects`). The filter is getting stripped at the API layer here<https://github.com/openstack/cinder/blob/stable/2024.1/cinder/volume/api.py…>. This is a blocker for auditability and integrating with third-party CMDB systems, as granting full admin access for these tools isn't a secure option. We’ve seen similar functionality handled in other services like Nova (e.g., `os_compute_api:servers:index:get_all_tenants` for SystemReader), as well as in Keystone and Neutron via policy tuning. Is there a particular reason this pattern hasn’t been implemented yet in Cinder? And would it make sense to consider making this configurable via the `volume:get_all_tenants_filter` policy rule? Appreciate any insights! Best regards, Serhii K.

1 0

The Placement API endpoint was not found
by mitku.bade＠mitm-tech.com 18 Jun '25

18 Jun '25

I was trying to setup a three node (controller, compute, and neutron)openstack environment manually using ubuntu 22.04 and the openstack caracal 2024.1 release. Every instance that I have created went into cell0 ,while I expect it to went into cell1 .Plus, the cells and the hots mapping are correctly configured and are working without error .But, I face an error which related to the Placement API endpoint. Running nova-status upgrade check returns the Placement API with Failure , while the other checks such as cellV2 are successful. Also running the nova-scheduler log returns The placement API endpoint was not found :keystoneauth1.exceptions.catalog.endpointnotfound:couldnot find the requested endpoint in service catalog. I validated the [placement],[keystone_Authtoken],[DEFAULT]],[database] settings, the endpoint,service,role of placement to be correct .It has been many days .Any one to stretch his/her support on this ?

2 2

[manila] No weekly meeting tomorrow Jun 18
by Carlos Silva 18 Jun '25

18 Jun '25

Hello, Tomorrow is a holiday for some people in the US and in Brazil, and that impacts on the attendance of the meeting, so let's cancel the meeting. Please ping me on email or in #openstack-manila in case you'd like to bring up something. Thank you, carloss

1 1

VMware Migration Guide - It’s LIVE!
by Kendall Nelson 18 Jun '25

18 Jun '25

Hello Everyone, Over the last few months, the VMware Working Group has been hard at work crafting a more in depth, detailed follow up to the initial VMware Migration Whitepaper. The goal of this follow up effort is to do a deeper dive into what migration away from VMware to OpenStack could look like, the considerations, the benefits, the key pieces that OpenStack offers to meet the needs of the workloads being migrated, etc. I am pleased to announce the VMware Migration Guide <https://www.openstack.org/vmware-migration-to-openstack/vmware-to-openstack…> ! Please feel free to share this document with the larger industry, future or present customers, and anyone else looking to learn more about what it means to migrate from VMware to OpenStack. We, the working group, really hope that this resource will provide all of the answers to common questions (and more!) about the migration process and help sustain this huge resurgence of OpenStack. Additionally, we’ll be putting together a series of Superuser posts on case studies around VMware migration. If you or your company have not already submitted one, now is the time! You can send them to kendall(a)openinfra.dev! Thank you to the VMware Working Group for all of the hard work, expertise, and knowledge shared to put together this HUGE achievement. -- Kendall Nelson *Senior Upstream Developer Advocate* The OpenInfra Foundation <https://openinfra.dev/>

1 0

[cinder] Unexpected Ceph RBD snapshot retention behavior when deleting image-based volumes
by Rocha Lobo, Vinicius 18 Jun '25

18 Jun '25

Hi, OpenStack Community. I'm part of the StarlingX Community and our starlingx-openstack distribution is currently delivering the 2024.1 (Caracal) release. We are facing an issue when using Cinder with the Ceph RBD backend: volumes created from Glance images leave behind protected snapshots and *.deleted volumes in the cinder-volumes pool after deletion, and these remnants are not being cleaned up automatically, even though I’ve enabled deferred deletion and garbage collection. So, I'm writing this email to explain our current issue and get feedback on this new Launchpad [1] I’m creating for Cinder. Environment: * OpenStack version: 2024.1 (Caracal) * Ceph version: Reef * Cinder configuration (via Helm override): conf: cinder: backend_defaults: rbd_flatten_volume_from_snapshot: True enable_deferred_deletion: True deferred_deletion_purge_interval: 10 ceph: image_volume_cache_enabled: False Issue description: 1) Create volume(s) from an image: * openstack volume create --image <image_id> --size 100 volume-test 2) Cinder creates a protected snapshot of the source image and then clones from it (as expected due to Ceph’s requirement for protected snapshots when cloning). 3) Delete the volume(s) via OpenStack CLI: * openstack volume delete volume-test After the deletion the corresponding RBD image and its snapshot are not cleaned up: * rbd -p cinder-volumes ls -l NAME SIZE PARENT FMT PROT LOCK <uuid>.deleted 100 GiB 2 <uuid>.deleted@<clone_snap>.clone_snap 1 GiB 2 yes... Even with the garbage collection features enabled (enable_deferred_deletion, rbd_flatten_volume_from_snapshot, and deferred_deletion_purge_interval), these protected snapshots and deleted volumes persist indefinitely, unless I clean them manually: * rbd snap unprotect <volume>.deleted@<snapshot> -p cinder-volumes * rbd snap rm <volume>.deleted@<snapshot> -p cinder-volumes * rbd rm <volume>.deleted -p cinder-volumes Here’s the logs that cinder pod shows while trying to delete the volume each 10 seconds: 2025-05-28 19:44:48.079 8 INFO cinder.volume.drivers.rbd [-] Purging trash for backend 'ceph-store' 2025-05-28 19:44:58.076 8 INFO cinder.volume.drivers.rbd [-] Purging trash for backend 'ceph-store' 2025-05-28 19:45:08.081 8 INFO cinder.volume.drivers.rbd [-] Purging trash for backend 'ceph-store' Questions: * Is this behavior expected in Cinder/CEPH integrations? * Shouldn't Cinder unprotect/delete the snapshot when the last volume, depending on how it is removed? Any insights or best practices would be greatly appreciated. Thanks in advance, Vinicius Lobo StarlingX contributor [1] https://bugs.launchpad.net/cinder/+bug/2114853

2 1

[all][tc][cyborg] Call for cyborg project maintainers
by Ghanshyam Maan 17 Jun '25

17 Jun '25

Hello Everyone, Cyborg project is lacking the active maintenance. The gate is broken, no response on the fix[1]. Two weeks ago, Sean raised the conern to ML[2] but there is no response from current core. We discussed it in TC meeting (last week[3] and today[4]) and as per foundation staff reachout, the next step is to call for new maintainers. If anyone using or interested to maintain it then this is right time to step up. Also, I would like existing maintainers (first of all, thanks for maintaining it till now) to give more insight about project status and their bandwidth which can help new maintainers to onboard. As per TC process to check project status, I have proposed to mark cyborg as inactive[5], feel free to provide your opinion here or in gerrit. If we do not hear back and mark project Inactive, there will be no cyborg project deliverables release in this cycle. [1] https://review.opendev.org/c/openstack/cyborg/+/949772 [2] https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack… [3] https://meetings.opendev.org/meetings/tc/2025/tc.2025-06-10-17.00.log.html#… [4] https://meetings.opendev.org/meetings/tc/2025/tc.2025-06-17-17.00.log.html#… [5] https://review.opendev.org/c/openstack/governance/+/952798 -gmaan

1 0

Nova bug report #2114855
by Vicentini Fracarolli, Joao 17 Jun '25

17 Jun '25

Hello OpenStack Community, I'm part of the StarlingX Community and our starlingx-openstack distribution is currently delivering the 2024.1 (Caracal) release. We were exploring the openstack-client "server rebuild" feature [1], and we might have found a bug. So, I'm writing this email to explain our current issue and get feedback on this new Launchpad we are creating for the Nova component https://bugs.launchpad.net/nova/+bug/2114855 [2]. It happened in the following scenario: * Create a VM with some small disk flavor and a small image. For example, using a flavor of 1 GB with the Cirros image (~ 21 MB of disk size). * Try to rebuild the VM using a new image. Example: the ubuntu-jammy qcow image. When the steps above are executed with an image with a disk size greater than the flavor size, the Nova API returns an error and the VM is not rebuilt: Flavor's disk is too small for requested image. Flavor disk is 1073741824 bytes, image is 1283063808 bytes. (HTTP 400) (Request-ID: req-7db974bb-15f3-425f-b97b-98b789b7e10f) But when we use an image with a disk size smaller than the flavor disk size, but with a virtual size bigger than the flavor disk size, Nova will try to rebuild the VM and fail: the VM state will be ERROR. It looks like the Nova API is accepting such rebuild requests, but when Nova Compute checks for virtual size, it fails. Is that expected behavior? Shouldn't the Nova API reject the request with an explicit warning telling the user to resize the VM before trying to rebuild? Thank you very much [1] https://docs.openstack.org/python-openstackclient/latest/cli/command-object… [2]https://bugs.launchpad.net/nova/+bug/2114855 Bug #2114855 “VM rebuild starts even if image virtual size is gr...” : Bugs : OpenStack Compute (nova)<https://bugs.launchpad.net/nova/+bug/2114855> Description =========== Openstackclient + Nova API accept to rebuild server with virtual size greater than the specified flavor’s disk size. Steps to Reproduce ================== 1 - Create a server specifying a flavor with small disk size (example: 1 GB) and an image small enough to fit. openstack flavor create --ram 512 --disk 1 --vcpus 1 tiny openstack server create –flavor tiny –image cirros vm-test 2 - Try to rebuild the server using a larger image but that still fits. It’s v... bugs.launchpad.net

2 1

[nova] multiple pci types with same address
by Arnaud Morin 17 Jun '25

17 Jun '25

Hello nova team, Quick question regarding support for multiple types (see [1]) with the same address: {vendor_id: "10de", product_id: "233b", "address": "00000000:03:00.0", "resource_class": "CUSTOM_H200_A"} {vendor_id: "10de", product_id: "233b", "address": "00000000:04:00.0", "resource_class": "CUSTOM_H200_A"} {vendor_id: "10de", product_id: "233b", "address": "00000000:44:00.0", "resource_class": "CUSTOM_H200_A"} {vendor_id: "10de", product_id: "233b", "address": "00000000:45:00.0", "resource_class": "CUSTOM_H200_A"} {vendor_id: "10de", product_id: "233b", "address": "00000000:83:00.0", "resource_class": "CUSTOM_H200_B"} {vendor_id: "10de", product_id: "233b", "address": "00000000:84:00.0", "resource_class": "CUSTOM_H200_B"} {vendor_id: "10de", product_id: "233b", "address": "00000000:C3:00.0", "resource_class": "CUSTOM_H200_B"} {vendor_id: "10de", product_id: "233b", "address": "00000000:C4:00.0", "resource_class": "CUSTOM_H200_B"} This works fine, I was able to define multiple aliases: {name: "h200a", device_type:"type-PF", resource_class: "CUSTOM_H200_A"} {name: "h200b", device_type:"type-PF", resource_class: "CUSTOM_H200_B"} I did that to create two blocks of 4 resources (A or B). But now, I need to create a flavor to boot instances with these devices. I want to have only one flavor that can use either A or B: For now I created a flavor with: pci_passthrough:alias='h200a:4' And was forced to create a second flavor with h200b:4. Is there any way to achieve a single flavor with both: Something like this? pci_passthrough:alias='h200a:4|h200b:4' I can't figure that out for now, is it possible? [1] https://docs.openstack.org/nova/latest/admin/pci-passthrough.html#support-f…

2 1

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

16 Jun '25

Hello Stackers, We're fifteen weeks away from the coordinated 2025.2 "Flamingo" release of OpenStack [1]. Milestone-2 is in a couple of weeks. This milestone is observed by several project teams for bug targeting. From the point of view of OpenStack's governance, this milestone serves as a point where we vet project deliverables to be included in the coordinated release. Releases are not tagged for deliverables from project teams that are deemed "inactive" [2]. In OpenStack, a project team is considered "inactive" when it no longer has regular contributor engagement or ongoing development. This often reflects that the problem the project once addressed is now being solved more effectively by another solution—either within or outside OpenStack. Inactivity isn't a failure, but rather a natural sign of how technology needs evolve over time. Any community member can propose a change to mark a project team inactive prior to Milestone-2. Doing so will prevent shipping broken or unmaintained code. In the past week, the OpenStack Technical Committee did not make any new governance changes. The team's focus has been on the implementation of the DCO by our deadline of 2025-07-01. I'd like to gently remind you that beyond July 1st, changes without a "Signed-off-by" line in the commit message cannot be uploaded to Gerrit. If you have a project team meeting before this date, please let folks know about this change. === Weekly Meeting === The last weekly meeting of the TC was held over IRC on OFTC's #openstack-tc channel on Tuesday, 2025-06-10 [3]. The main focus of the meeting was tracking all the changes necessary for enforcing the Developer Certificate of Origin in lieu of the ICLA beginning on 2025-07-01 [4]. We noted changes to various infrastructure pieces, and while we're hoping for a smooth transition, we do anticipate some hiccups. We are hoping for the community's patience and cooperation as we iron out the kinks. Further, concerns were raised about the Cyborg project's apparent inactivity. The last change merged into Cyborg was over two months ago, and a critical CI fix remains open, lacking review attention. Efforts to engage the team via the mailing list have not yielded any response, and there is no recent activity on IRC or Gerrit. While it's known that the Cyborg team has historically preferred WeChat/Weixin for communication, relying on unofficial channels or Foundation staff for outreach isn’t sustainable. The TC agreed that it’s important to determine whether the project is defunct or simply in need of new leadership, and to encourage maintainers to monitor and respond through community channels. Additionally, a self-report from the Vitrage team indicated that Tempest tests are currently failing due to a lack of contributor time this cycle. With the M-2 milestone deadline approaching on July 3rd, we emphasized the importance of project teams providing accurate and timely updates to the release team. The next meeting of the OpenStack TC is today, 2025-06-17. It'll be held over IRC in OFTC's #openstack-tc channel at 1700 UTC. Please find the agenda on the meeting's wiki page [5]. I hope you'll be able to join us. === Governance Proposals === ==== Open for review ==== - Require declaration of affiliation from TC Candidates | https://review.opendev.org/c/openstack/governance/+/949432 === Upcoming Events === - 2025-07-03: OpenStack's 15th Birthday, Colombia User Group: https://www.meetup.com/colombia-openinfra-user-group/events/308383244 - 2025-06-28: OpenInfra+Cloud Native Day, Vietnam: https://www.vietopeninfra.org/void2025 - 2025-07-19: OpenInfra Days, Indonesia: https://2025.openinfra.id/ === How to Contact the TC === You can reach the TC in several ways: - Email: Send an email with the tag [tc] on this mailing list. - IRC: Ping us using the tc-members keyword on the #openstack-tc IRC channel on OFTC. - Meeting: Join us at our weekly meeting. The Technical Committee meets every week on Tuesdays at 1700 UTC [4]. 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] Inactive projects: https://governance.openstack.org/tc/reference/emerging-technology-and-inact… [3] TC Meeting IRC Log 2025-06-10: https://meetings.opendev.org/meetings/tc/2025/tc.2025-06-10-17.00.html [4] Replace ICLA with DCO: https://governance.openstack.org/tc/resolutions/20250520-replace-the-cla-wi… [5] TC Meeting Agenda, 2025-06-17: https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Next_Meeting

1 0