August 2025 - openstack-discuss - lists.openstack.org

[all][elections][ptl][tc] Combined PTL/TC 2026.1 cycle Election Nominations Last Days
by Sławek Kapłoński 18 Aug '25

18 Aug '25

Hi, A quick reminder that we are in the last hours for declaring PTL and TC candidacies. Nominations are open until Aug 20, 2025 23:45 UTC. If you want to stand for election, don't delay, follow the instructions at[1] to make sure the community knows your intentions. Make sure your nomination has been submitted to the openstack/election repository and approved by election officials. All members of the community are encouraged to confirm their email address and opt in to the CIVS election as described at: https://governance.openstack.org/election/#electorate Election statistics[2]: Nominations started @ 2025-08-06 23:45:00 UTC Nominations end @ 2025-08-20 23:45:00 UTC Nominations duration : 14 days, 0:00:00 Nominations remaining : 2 days, 14:27:12 Nominations progress : 81.41% --------------------------------------------------- Projects[1] : 38 Projects with candidates : 8 ( 21.05%) Projects with election : 1 ( 2.63%) --------------------------------------------------- Need election : 1 (Horizon) Need appointment : 30 (Adjutant Barbican Blazar Cloudkitty Cyborg Glance Heat Keystone Magnum Manila Masakari Mistral Monasca Neutron Nova Octavia OpenStackAnsible OpenStackSDK OpenStack_Charms Puppet_OpenStack Quality_Assurance Rall y Storlets Sunbeam Swift Tacker Telemetry Trove Venus Vitrage) --------------------------------------------------- TC Candidates : 2 (4 Required) =================================================== Stats gathered @ 2025-08-18 09:17:48 UTC This means that with approximately 2 days left, 30 projects will be deemed leaderless. In this case the TC will oversee PTL selection as described by [3]. Thank you, [1] https://governance.openstack.org/election/#how-to-submit-a-candidacy [2] Any open reviews at https://review.opendev.org/q/project:openstack/election+is:open+file:candid… have not been factored into these stats. [3] https://governance.openstack.org/resolutions/20141128-elections-process-for… -- Slawek Kaplonski Principal Software Engineer Red Hat

1 0

[neutron] Bug deputy report (week starting on August 11)
by Bernard Cafarelli 18 Aug '25

18 Aug '25

Hey neutrinos, we switched the deputy order with Miro, so here is the list of bugs reported last week It was quiet most of the week, though activity picked up a bit in the end (thanks Brian for checking the recent ones). Overall, medium priority bugs are in progress, with a patch proposed or even merged. The metadata agent one is worth digging into, and we have one on vpnaas that need relevant eyes High * [OVN] Metadata agent errors when returning gzip-encoded data - https://bugs.launchpad.net/bugs/2120723 Reported on 2025.1, Brian asked for more info (up-to-date deployment, possible to test on master) Medium * Neutron FWaaS logapi fails to notify for already deleted ports - https://bugs.launchpad.net/bugs/2120429 Patch proposed and merged: https://review.opendev.org/c/openstack/neutron-fwaas/+/956013 * Limit threads for metadata haproxy - https://bugs.launchpad.net/bugs/2120668 Patch proposed: https://review.opendev.org/c/openstack/neutron/+/955951 * Dual-stack networks are not handled correct by OVS DHCP plugin - https://bugs.launchpad.net/bugs/2120758 Patch proposed: https://review.opendev.org/c/openstack/neutron/+/957594 New * Dalmatian: Second IPsec site connection on same VPN service/router stays PENDING_CREATE; no agent-side rendering (works on Zed L3 agent) - https://bugs.launchpad.net/bugs/2120316 VPNaaS issue with ML2/OVS, we have similar open issues but on ML2/OVN - Needs vpnaas eyes Proposed RFE * Add metadata caching for immutable values - https://bugs.launchpad.net/bugs/2120732 * Set additional search domains via DHCP - https://bugs.launchpad.net/bugs/2120740 Regards, -- Bernard Cafarelli

1 0

[manila] Share network subnets unclean
by Rico Lin 18 Aug '25

18 Aug '25

Hi Manila core team We have an issue with share network teardown that leaves subnet unclean when no router information is provided. This led to a huge list of subnets stay unclean with manila CSI plugin in Kubernetes. The fix is here: https://review.opendev.org/c/openstack/manila/+/955996 It would be appreciated if you could kindly provide your review on this. Thank you *Rico Lin*

1 0

[release] Release countdown for week R-6, Aug 18 - 22
by Elõd Illés 15 Aug '25

15 Aug '25

Development Focus ----------------- Work on libraries should be wrapping up, in preparation for the various library-related deadlines coming up. Now is a good time to make decisions on deferring feature work to the next development cycle in order to be able to focus on finishing already-started feature work. General Information ------------------- We are now getting close to the end of the cycle, and will be gradually freezing feature work on the various deliverables that make up the OpenStack release. This coming week is the deadline for general libraries (except client libraries): their last feature release needs to happen before "Non-client library freeze" on August 21st, 2025. Only bugfixes releases will be allowed beyond this point. When requesting those library releases, you can also include the stable/2025.2 branching request with the review (as an example, see the "branches" section here: https://opendev.org/openstack/releases/src/branch/master/deliverables/pike/… In the next weeks we will have deadlines for: * Client libraries (think python-*client libraries), which need to have their last feature release before "Client library freeze" (August 28th, 2025) * Deliverables following a cycle-with-rc model (that would be most services), which observe a Feature freeze on that same date, August 28th, 2025. Any feature addition beyond that date should be discussed on the mailing-list and get PTL approval. As we are getting to the point of creating stable/2025.2 branches, this would be a good point for teams to review membership in their $project-stable-maint groups. Once the stable/2025.2 branches are cut for a repo, the ability to approve any necessary backports into those branches for 2025.2 "Flamingo" will be limited to the members of that stable team. If there are any questions about stable policy or stable team membership, please reach out in the #openstack-stable channel. Upcoming Deadlines & Dates -------------------------- Non-client library freeze: August 21st, 2025 (R-6 week) Client library freeze: August 28th, 2025 (R-5 week) Flamingo-3 milestone: August 28th, 2025 (R-5 week) Cycle Highlights Due: September 4th, 2025 (R-4 week) 2025.2 "Flamingo" final release: October 1st, 2025 OpenInfra Summit Europe: October 17th-19th, 2025 Előd Illés irc: elodilles @ #openstack-release

1 0

[magnum] Deploying Openshift with Magnum
by Winicius Allan 15 Aug '25

15 Aug '25

Hi community, Currently, is it possible to deploy an Openshift cluster using Magnum? I do not find anything on docs, nor on drivers. If it is not possible, is there any effort to add this feature in the future? Thanks in advance

1 0

[PTL][Nova][Swift][Cyborg][Keystone][Neutron][Horizon][Skyline] OpenStack for AI Whitepaper: August 14 Meeting Recording & Recap
by Kendall Nelson 15 Aug '25

15 Aug '25

Hello Everyone! Thank you again to those that were in attendance today and also those that have already been contributing to the whitepaper! We are making some solid progress. For those that weren't able to make it, in today's meeting we did another walkthrough of the working document and outline with the new subsection additions <https://docs.google.com/document/d/1NjxIyWF6aUFg0jb0HewX1JmOyploYV5Dxe3j1Lt…>. I talked a little bit about inclusion of specific images that have been added and that I am trying to keep up with comments and questions in the doc. I also reiterated our timeline (trying to have all the content largely drafted by September 1) and a reminder that providing a reference architecture is open to all OpenInfra Platinum, Gold and Silver members and that case studies can be provided by OpenInfra Platinum and Gold members for inclusion in the whitepaper. The deadline for both reference archs and case studies is September 19th. If you know you will not make the deadline please reach out to us ahead of time and we can try to make accommodations, but largely after that date we will not be able to include additions due to website building and other planning that will be the final phase before publication at the OpenInfra Summit Europe. You can watch the recording of today's meeting here <https://zoom.us/rec/share/JSacqoVVH9hmBriq9XRM69IyxCoRWnNykQj5T0GScln85SDP4…> . WRT OpenStack teams, I want to call out some of the comments and sections in the doc: We are in need of your perspective! I had added some of the PTLs directly in comments, but anyone from any project team is welcome to get involved in the whitepaper. Generally the projects I tagged in the subject line of this email are ones we would love content from, but if there are others that should be or want to be included, we can figure that out as well. As always if you have any questions, please feel free to drop them here or in the working doc <https://docs.google.com/document/d/1NjxIyWF6aUFg0jb0HewX1JmOyploYV5Dxe3j1Lt…>, or generally on the ML. As another reminder, next week will be an asych check in. I look forward to seeing more of your content in the doc by then! Thank you everyone for your effort and collaboration! -- Kendall Nelson *Senior Upstream Developer Advocate* The OpenInfra Foundation <https://openinfra.dev/>

3 2

[nova] Image Encryption patch
by Josephine Seifert 15 Aug '25

15 Aug '25

Hi nova folks, We worked on the LUKS-based image encryption and the patches Cinder and Glance are in a good state now + we also have tempest tests. Here you can see the overall state: https://review.opendev.org/q/topic:%22LUKS-image-encryption%22 There is one patch in nova, which adresses an issue with keys for the encrypted image/volume being either used directly or being hexlified beforehand. We would be really happy if you could review this nova patch: https://review.opendev.org/c/openstack/nova/+/926326 So we can hopefully finish our work on the Image encryption. greetings Josephine (Luzi)

4 6

[Neutron][VPNaaS] VPN service/router stays PENDING_CREATE - 2024.2 Dalmatian
by Shubham Yadav 15 Aug '25

15 Aug '25

Hello, On OpenStack Dalmatian, creating a second IPsec site connection on the same VPN service/router remains stuck in PENDING_CREATE indefinitely. Environment: OpenStack services in Kubernetes (OpenStack-Helm style) Neutron L3 agent with VPNaaS (strongSwan driver) L3 agent hosts the router as master, VPNaas enabled Observed: Works: First IPsec connection renders in ipsec.conf / ipsec.secrets and comes up. Fails (Dalmatian): Adding a second connection on the same VPN service/router: Status: PENDING_CREATE (no progress) No L3/VPNaas logs for the event, no strongSwan activity No config changes in /var/lib/neutron/ipsec/<router_uuid>/etc/ Control test: Switching only the L3 agent container to a Zed image in the same environment → second connection renders immediately and tunnel comes up. Repro Steps: Create router + VPN service. Create IKE/IPsec policies. Create first site connection (OK). Create second site connection (different peer, same VPN service/router). Expected: Second connection renders a new conn in ipsec.conf, appends secret, and comes up. Actual (Dalmatian): No rendering, stuck PENDING_CREATE, no processing logs. This seems like a Dalmatian regression in L3/VPNaas handling of multiple connections per VPN service. waiting for a reply Best regards, Shubham

1 0

[nova] compute's reaction to finding unmanaged VMs
by Bence Romsics 14 Aug '25

14 Aug '25

Hi Nova Team, How does Nova relate to having unmanaged libvirt VMs alongside VMs managed by nova-compute? Is this considered supported, unsupported, or somewhere in between? I know about the warning in [1] and the compute startup time exception in [2]. Colleagues working on a major OpenStack version uplift in a downstream OpenStack distro started encountering the above exception. This distro utilizes some non-Nova-managed VMs (in particular, to orchestrate the OpenStack deployment itself). To reduce the deployment footprint, these VMs are co-located with Nova-managed VMs. AFAIU, this exception was introduced by the stable-compute-uuid blueprint [3]. With that in mind, I found this behavior: * Before the blueprint was implemented, Nova only logged a warning if it found an unmanaged VM. * After stable-compute-uuid, the compute service refuses to start in the same case. * If I make sure that the stable UUID is already present, then it seems to fall back to the earlier warning-only behavior. If I let nova-compute create the stable UUID itself, this leads to somewhat surprising behavior: * If nova-compute finds an unmanaged VM during its first startup, it refuses to start. * If it finds an unmanaged VM only during its second (or subsequent) startup (when the stable UUID has already been generated), it starts and logs a warning only. This made me think that the distro should pre-generate the compute UUID. Then I found in the stable-compute-uuid blueprint (and in the docs [4]) that this approach is clearly supported. It seems the compute service does not look at the metadata present in the libvirt domain definitions, and I started wondering why. AFAICT, the exception introduced by the stable-compute-uuid blueprint only really applies if Nova finds VMs that contain Nova metadata but are unknown to the compute service starting up. And this line of thought led me to my original question and these: * Could/should nova-compute inspect the metadata of libvirt VMs at startup and act differently if an unexpected VM has (or doesn’t have) Nova metadata? Would this be considered a meaningful Nova feature? Or should the distro just pre-generate the stable UUID and ignore the warning (as it did before the blueprint)? * Does Nova currently not look at the libvirt domain definition metadata simply because nobody has implemented this yet? Or is there another reason? * Is it considered supported (and to what level) to have non-Nova-managed VMs co-located with Nova-managed VMs? Thanks in advance, Bence Romsics (rubasov on irc) [1] https://github.com/openstack/nova/blob/54b65d5bf2b23fa8a4612fd3adddc8751192… [2] https://github.com/openstack/nova/blob/54b65d5bf2b23fa8a4612fd3adddc8751192… [3] https://specs.openstack.org/openstack/nova-specs/specs/2023.1/implemented/s… [4] https://docs.openstack.org/nova/latest/admin/compute-node-identification.ht…

4 5

Volume retype fails with Libvirt Nova - disk does not have active block job
by Karl Kloppenborg 14 Aug '25

14 Aug '25

Hi Openstackers. We’re currently migrating between storage backends and for the most part retype works correctly. However some VM’s fail the volume migration/retype quickly with the following error: Stack trace here: https://gist.github.com/inventionlabsSydney/40cd945685c798c489d729d2bcd5ec1e Has anyone else experienced this, we have tried looking around on the web and haven’t seen anything related to this. Much appreciated. 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>

1 0