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

Floating IP randomly becomes unreachable from external network (OSA AIO 30.0.2, Ubuntu 24.04)
by christophel＠silival.com 28 Jun '25

28 Jun '25

Hello, I’m currently running an OpenStack-Ansible All-In-One deployment (version 30.0.2) on Ubuntu 24.04. The environment hosts several virtual machines across multiple tenant networks. Each VM is assigned a floating IP from a public 172.x.x.x range, which allows access from the controller host and external clients. The issue From time to time, a VM becomes unreachable via its floating IP. The instance is still: Running normally. Reachable from other VMs on the same internal tenant network using its private IP (10.x.x.x). Associated with the same security groups and port configuration as before. This happens without any apparent trigger or configuration change. I can still ping and SSH to other VMs’ floating IPs, so the problem is isolated to one instance at a time. Workaround The only way I’ve found to restore external access is: Disassociate and delete the current floating IP. Allocate a new floating IP from the same pool. Associate it to the same VM port. Once the new floating IP is set, the VM becomes immediately reachable again. This has now occurred several times across different VMs. I’m concerned it will keep happening randomly. Question Has anyone encountered similar behavior with floating IPs in an OpenStack-Ansible AIO setup? Is there a known root cause, or any specific logs or areas I should investigate? If this mailing list is not the right place for this type of question, I’d also appreciate guidance on where to report it or who to contact. Thanks in advance for your help, Christophe.

3 7

[openstack]Detach and Attach Openstack Instance interfaces wont work
by Nguyễn Hữu Khôi 27 Jun '25

27 Jun '25

Hello. It is not a problem from Openstack but I think it will impact to our users https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/2115545 Nguyen Huu Khoi

1 0

[manila] Python-manilaclient functional tests hack-a-ton - Jun 30th - Jul 4th
by Carlos Silva 27 Jun '25

27 Jun '25

Hello zorillas and interested stackers, Our Flamingo hack-a-ton starts next Monday at 15:00 UTC. We've been closing the gaps on OSC for a while now, and we are getting close to wrap everything up prior to the removal of the manilaclient and fully focus on OSC. On this hack-a-ton, we will focus on adding more functional test coverage to the OSC commands. Hackathon Plan: * Task Assignments: participants are encouraged to create, claim, and edit Taiga cards for their chosen implementations. Recent additions can serve as inspiration. Please contact Carlos (carloss) to be added to the Taiga board. Additionally, please add yourself as a "watcher" to two other Taiga cards being implemented by others to serve as a code reviewer. * Code Submission Window: Code can be submitted between June 30th, 15:00 UTC, and July 4th, 15:00 UTC, to be considered part of this hackathon. * Kick-off Session: A one-hour kick-off session will be held on June 30th at 15:00 UTC. This session will cover environment setup and also how to implement and run tests in your environment. The doc was kindly prepared by Vida (vhari) and is already available [2] in case you'd like a headstart. * Mid-point Status Check: The Manila upstream weekly meeting hour will serve as a mid-point status check. [1] https://gist.github.com/silvacarloss/295ca27bc1d76aed6564ab05ebdea2c7 [2] https://docs.google.com/document/d/1n44DXYvn_HDvr-NIuL3k3SE_UxoH15swMn0zPbc… Looking forward to working with you! Regards, carloss

1 1

migrating to ovn
by Mario David 27 Jun '25

27 Jun '25

hi all after today's meetup I have compiled information/documentation about migrating to OVN here https://github.com/mariojmdavid/migrate-to-ovn feel free to check, comment, criticize, you can open issues or contribute the process is far from full bulletproof I have this openstack infra up and running in production, but there are a few points I am in doubt, and will need further discussion namely about the net namespace (I was used with ip netns exec qrouter.... on the nodes running the l3-agent), as well as how to properly configure SRIOV but will get there best Mario

1 0

Help Name the OpenStack 2026.1 "G" Release
by Allison Price 27 Jun '25

27 Jun '25

Hi everyone, It’s time to name the OpenStack 2026.1 “G” release. Below is a poll that will be open until this Friday, June 27 at 1700 UTC. Please submit your preferences and we will let you know once the winner has been identified. https://civs1.civs.us/cgi-bin/vote.pl?id=E_17c91bf2dbfe3a77&akey=d3d789cac3… Cheers, Allison

1 1

[release] Release countdown for week R-13, Jun 30 - Jul 04
by Elõd Illés 27 Jun '25

27 Jun '25

Development Focus ----------------- The Flamingo-2 milestone is next week, on July 3rd, 2025! 2025.2 Flamingo-related specs should now be finalized so that teams can move to implementation ASAP. Some teams observe specific deadlines on the second milestone (mostly spec freezes): please refer to https://releases.openstack.org/flamingo/schedule.html for details. General Information ------------------- Libraries need to be released at least once per milestone period. The release team will soon propose releases for any library that has not been otherwise released since milestone-1. PTL's and release liaisons, please watch for these and give a +1 to acknowledge them. If there is some reason to hold off on a release, let us know that as well. A +1 would be appreciated, but if we do not hear anything at all by the end of the week, we will assume things are OK to proceed. Remember that non-library deliverables that follow the cycle-with-intermediary release model should have an intermediary release before milestone-2. Those who haven't will be proposed to switch to the cycle-with-rc model, which is more suited to deliverables that are released only once per cycle. Next week is also the deadline to freeze the contents of the final release. All new '2025.2 Flamingo' deliverables need to have a deliverable file in https://opendev.org/openstack/releases/src/branch/master/deliverables/flami… and need to have done a release by milestone-2. Changes proposing those deliverables for inclusion in 2025.2 Flamingo have been posted, please update them with an actual release request before the milestone-2 deadline if you plan on including that deliverable in 2025.2 Flamingo, or -1 if you need one more cycle to be ready. Upcoming Deadlines & Dates -------------------------- Flamingo-2 Milestone: July 3rd, 2025 Előd Illés irc: elodilles @ #openstack-release

1 0

[neutron][os-ken] Bug on the BGP loop prevention
by anas.jouhdy＠gmail.com 27 Jun '25

27 Jun '25

Hi, As it is my first message here, do not hesitate to tell me if something is wrong with the ticket ! I think there is a bug in this file https://opendev.org/openstack/os-ken/src/branch/master/os_ken/services/prot… on the method "_is_looped_path_attrs" on line 1655. In the case we found a loop, we should return True instead of None. For example in my case, I have an Openstack BGP speaker that advertise correctly the reachable subnets in Openstack. The external peer (Cumulus switch in my case) re-advertise the IP prefix of the subnets to my Openstack BGP speaker when it learns them. This rightfully raise an error in the log thanks to this method "_is_looped_path_attrs" telling that the update coming from the external peer will be ignored as the local AS was found in the AS Path but after that, the debug log implies that the path was still added to the potential path that can reach the subnet. This then become an issue when we detach our subnet from the router, because only the local path will be removed and the route will not be withdrawn (because the new best path will be the "false" route learned back from Cumulus) Do not hesitate to ask for precision !

3 2

Ops Radio!
by Chris Morgan 27 Jun '25

27 Jun '25

We'll do another Ops Radio today at 13:00 UTC which is in about 20 minutes from now as I write. See https://etherpad.opendev.org/p/openstack_ops_radiohour "*What is "OpenStack Ops Radio Hour"? * A casual setting for operators, engineers, and contributors to come together, share knowledge, and collaborate on the complexities of managing and deploying OpenStack environments." -- Chris Morgan <mihalis68(a)gmail.com>

1 0

[cinder] Volume to Image Upload with Multi-Store Backends (Cinder + Glance)
by Maximilian Stinsky-Damke 27 Jun '25

27 Jun '25

Greetings, I'm in the process of setting up a new OpenStack deployment where both Cinder and Glance are configured with multiple Ceph-based backends using the multi-store functionality. Basic operations (create, delete, snapshot, upload, etc.) work fine for each store in both services. However, I'm encountering issues when trying to upload a Cinder volume to Glance as an image in this setup. My understanding is that when the volume type does not include image_service:store_id, Cinder should upload the image to the default Glance store. However, in my case, this upload fails with the following error: ERROR oslo_messaging.rpc.server FileNotFoundError: [Errno 2] No such file or directory: '/etc/ceph/ceph.client.cinder.keyring' I'm having trouble understanding why Cinder is trying to access this particular keyring. Each of my Cinder backends has its own Ceph config and keyring pointing to the appropriate cluster, and everything else works correctly. Here are my specific questions: 1. Should Cinder not be uploading the volume to Glance via the API, without needing direct access to the Glance Ceph store? 2. If Cinder is expected to access the Glance backend directly (e.g., to optimize data movement), how does it determine which Ceph config and keyring to use? 3. Is there any documentation or configuration guidance available on how to tell Cinder which credentials to use when interacting with Glance stores? Any insights or pointers would be greatly appreciated. Best regards, Max

3 4

[Cinder][Nova] - Volume retype fails with libvirt error about active block job
by Karl Kloppenborg 26 Jun '25

26 Jun '25

Hi Cinder + Nova Teams. Live migrating between two storage backends, most VM’s move successfully, but we’re seeing several VM’s fail the retype with the following error: https://gist.github.com/inventionlabsSydney/137121e8a4772ea3562776c10f43371a Libvirt logs show the following: 2025-06-26 06:55:48.906+0000: 2509009: error : qemuDomainBlockJobAbort:13723 : invalid argument: disk sda does not have an active block job 2025-06-26 06:57:08.879+0000: 2509006: error : qemuDomainBlockJobAbort:13723 : invalid argument: disk sda does not have an active block job 2025-06-26 06:57:09.053+0000: 2509009: error : qemuDomainBlockJobAbort:13723 : invalid argument: disk sda does not have an active block job 2025-06-26 23:24:19.954+0000: 2509008: error : qemuDomainBlockJobAbort:13723 : invalid argument: disk sda does not have an active block job 2025-06-26 23:24:20.130+0000: 2509009: error : qemuDomainBlockJobAbort:13723 : invalid argument: disk sda does not have an active block job Has anyone else encountered similar to this, we cannot seem to find any difference between VM’s that are working and VM’s that fail this retype. Openstack details: Version Epoxy. Compiled against library: libvirt 10.0.0 Using library: libvirt 10.0.0 Using API: QEMU 10.0.0 Running hypervisor: QEMU 8.2.2 Migration backends: From: Ceph. To: PowerFlex. 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>

1 0

[dev] OpenStack Templateless Provisioning
by prmjh4＠gmail.com 26 Jun '25

26 Jun '25

Do we have any mechanism in OpenStack environment where we do not need an appropriate template already exists in the OpenStack environment in order to create server instance on the OpenStack Cloud programmatically? where we can do the templateless provisioning of the server instance on OpenStack?

5 10

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 2

[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

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

[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