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

[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 17 Aug '25

17 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

[horizon][cinder] service type block-storage not activated
by Eugen Block 14 Aug '25

14 Aug '25

Hi all, during further testing of my upgraded Epoxy cloud (before upgrading our production cloud) I noticed this error message in the browser console when analyzing the response times with the dev tools: > Possibly unhandled rejection: Diensttyp ist nicht aktiviert: block-storage "Diensttyp ist nicht aktiviert" translates to "service type is not activated". But looking at the service versions, there is an entry for "block-storage": root@controller01:~# openstack versions show | grep storage Could not load 'message_list': module 'zaqarclient.queues.v2.cli' has no attribute 'OldListMessages' Could not load 'message_post': module 'zaqarclient.queues.v2.cli' has no attribute 'OldPostMessages' | RegionOne | block-storage | 3.0 | CURRENT | https://controller.domain:8776/v3/ | 3.0 | 3.71 | I remembered this thread [0] and read it again, but I'm still insecure if I need to change anything or not. Our production cloud has been created around 10 years ago, so I'm pretty sure there are many legacy things one could clean up. But could anyone please clarify if something is missing here or not? Or is it a red herring in horizon? I'd really appreciate any pointers! Thanks! Eugen [0] https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack…

1 2

[nova][elections][ptl] Application for the PTL role 2026.1
by René Ribaud 13 Aug '25

13 Aug '25

Hello, I am announcing my new candidacy for the PTL role for Nova and Placement. Serving as PTL in the Flamingo cycle was both a rewarding and instructive experience. It allowed me to learn the responsibilities and workload of the role, build stronger connections across the community, and help contributors move their work forward. In the next cycle, I want to continue fostering a welcoming and collaborative environment for all contributors. I will continue and improve our efforts to enhance bug triage, reduce the number of open bugs, and support timely reviews to help features progress toward completion. I am also eager to follow and participate in the Eventlet removal effort, which began in Flamingo and represents a major step for OpenStack. This is a particularly interesting challenge—not highly visible to most users, but crucial for the long-term health, performance, and maintainability of the project. My main focus, and the most important thing to me, will remain ensuring that Nova and Placement stay robust, maintainable, and aligned with our users’ needs. Thank you for your trust so far, I’d be happy to continue serving in this role. Thanks, René

1 0

[publiccloud-sig] Public Cloud SIG meeting d.d. 13 August
by Kees Meijs | Nefos 12 Aug '25

12 Aug '25

Hello Stackers, On Wednesday 13 August the bi-weekly Public Cloud SIG meeting will be held again. The publicly available video meeting will be conducted from 07:00 hrs UTC (09:00 hrs CEST) and on here: https://meetpad.opendev.org/publiccloud-sig Additional information to be found on https://wiki.openstack.org/wiki/PublicCloudSIG Since I'm vacationing during the meeting, I won't be joining myself. Cheers, Kees __ Kees Meijs BICT Nefos Cloud & IT <https://nefos.com/contact> Nefos IT bv Burgemeester Mollaan 34a 5582 CK Waalre - NL kvk 66494931 +31 (0)88 2088 188 <tel:+31882088188> nefos.com <https://nefos.com/contact> The information contained in this message is intended for the addressee only and may contain classified information. If you are not the addressee, please delete this message and notify the sender; you should not copy or distribute this message or disclose its contents to anyone. Any views or opinions expressed in this message are those of the individual(s) and not necessarily of the organization. No reliance may be placed on this message without written confirmation from an authorised representative of its contents. No guarantee is implied that this message or any attachment is virus free or has not been intercepted and amended. General terms and conditions ("The NLdigital Terms") apply to all our products and services.

1 1

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

11 Aug '25

Hello Stackers, We're two weeks away from a feature freeze across all projects following a "cycle-with-rc" release model [1]. This is a significant release milestone, and OpenStack project teams are hard at work on code review iterations to meet this deadline. In the past week, we kicked off elections for the next crop of OpenStack Project Team Leads as well as for four seats on the OpenStack Technical Committee [2]. These leadership positions are voluntary and form the bedrock of our community's principle of "Open Community" [3]. There is a long tradition of mentoring contributors to take on these important roles, and each comes with a unique opportunity to learn, impact OpenStack software, and give back to the community. If you're considering nominating yourself but need assistance, please do not hesitate to pop into #openstack-tc on OFTC and ask questions. The nomination period closes on August 20th. As far as governance updates are concerned, the OpenStack TC defined affiliation diversity within its charter and began the process of affirming liaisons for various projects following the "distributed project leadership" model of governance [4]. We also began the process of retiring the Monasca project team and its various deliverables. I'll keep you posted on the progress in the coming weeks. === Weekly Meeting === The last weekly meeting of the OpenStack Technical Committee was held simultaneously on Meetpad [5] and IRC [6]. Attendance was low due to summer break in various parts of the northern hemisphere where members hail from. We discussed how the Monasca retirement process will proceed. We also discussed the runtime update for the 2026.1 "Gazpacho" release, specifically the Python version to be supported. Debian 13 (Trixie) is set to release with Python 3.13, which is a key factor in our decision-making. Initial smoke tests on a Trixie devstack-integration test job appear promising. We addressed some concerns regarding the TC charter change regarding organizational affiliation. We also reviewed the gate's health, with recent reports of Debian job failures attributed to stale mirrors and cluster maintenance. We discussed the progress on the SRBAC community goal. There are several projects that have not yet completed Phase 1. We'll be following up on this during this week. We reminded folks that the OpenStack User Survey for 2025 is open and will close at the end of this month [7]. Please take the survey and spread the word. OpenStack project teams would appreciate feedback through the survey, and we are looking to discuss the results at the PTG in October. The next meeting of the TC is today, August 12, 2025, at 1700 UTC. This meeting will be hosted simultaneously over IRC, in OFTC's #openstack-tc channel. Please find the meeting's agenda in the wiki [8]. I hope you'll be able to join us. === Governance Proposals === ==== Merged ==== - Define "affiliation" within the context of the TC | https://review.opendev.org/c/openstack/governance/+/956024 - Add Extra ACs for governance repositories | https://review.opendev.org/c/openstack/governance/+/956836 - os-test-images never releases | https://review.opendev.org/c/openstack/governance/+/954249 - Add series names to runtimes doc | https://review.opendev.org/c/openstack/governance/+/955810 - Fix project_stats_check script | https://review.opendev.org/c/openstack/governance/+/955108 ==== Open for review ==== - Reset freezer project leadership from DPL back to PTL | https://review.opendev.org/c/openstack/governance/+/956918 - Reset oslo project leadership from DPL back to PTL | https://review.opendev.org/c/openstack/governance/+/956912 - Freezer - remove information about Disaster Recovery | https://review.opendev.org/c/openstack/governance/+/941893 - Reset Release Management project leadership from DPL back to PTL | https://review.opendev.org/c/openstack/governance/+/956916 - Reset watcher project leadership from DPL back to PTL | https://review.opendev.org/c/openstack/governance/+/956913 - Reset requirements project leadership from DPL back to PTL | https://review.opendev.org/c/openstack/governance/+/956915 - Remove Monasca from active project | https://review.opendev.org/c/openstack/governance/+/953671 - Require declaration of affiliation from TC Candidates | https://review.opendev.org/c/openstack/governance/+/949432 === Upcoming Events === - 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/ === 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. - Ping us using the 'tc-members' keyword on the #openstack-tc IRC channel on OFTC. - Join us at our weekly meeting: The Technical Committee meets every week on Tuesdays at 1700 UTC [8]. 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://lists.openstack.org/archives/list/openstack-discuss@lists.openstack… [3] Open Community: https://openinfra.org/four-opens/open-community/ [4] Refreshing liaisons for DPL projects: https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack… [5] TC Meeting Video Recording, Aug 5, 2025: https://youtu.be/e5LPZNjdIzM [6] TC Meeting IRC Log, Aug 5, 2025: https://meetings.opendev.org/meetings/tc/2025/tc.2025-08-05-17.00.html [7] Take the 2025 OpenStack User Survey: https://www.openstack.org/user-survey [8] TC Meeting Agenda, Aug 12, 2025: https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Next_Meeting

1 0

[tc][freezer][watcher][release][requirement][oslo][ironic] projects need to refresh the DPL model for the next cycle
by Ghanshyam Maan 11 Aug '25

11 Aug '25

Hi All, As you know, we have six projects (listed below) in the DPL model. As per process[1], we need to reset the DPL model every cycle. The project team either needs to opt-in to the DPL model by -1 from all currently listed liaisons (refer to the document for exact steps[1]) or plan for the PTL election. 1. Freezer: https://review.opendev.org/c/openstack/governance/+/956918 2. Watcher: https://review.opendev.org/c/openstack/governance/+/956913 3. Release: https://review.opendev.org/c/openstack/governance/+/956916 4. Requirement: https://review.opendev.org/c/openstack/governance/+/956915 5. Oslo: https://review.opendev.org/c/openstack/governance/+/956912 6. Ironic: https://review.opendev.org/c/openstack/governance/+/956917 [1] https://governance.openstack.org/tc/reference/distributed-project-leadershi… -gmaan

3 3

[tacker] Cancel weekly meeting on August 11th
by Yasufumi Ogawa 10 Aug '25

10 Aug '25

Hi team, Due to summer vacation, I'm going to cancel the IRC meeting this week. Thanks, Yasufumi

1 0

Inquiry: Integrating Tungsten Fabric with Neutron in Kolla Ansible 2023.1
by Thamanna Farhath 08 Aug '25

08 Aug '25

Hello OpenStack Community, We are currently using OpenStack Kolla Ansible (2023.1 release). As part of our networking design, we are evaluating the possibility of integrating Tungsten Fabric (TF) with Neutron. I would like to clarify the following points: Compatibility – Does the Kolla Ansible 2023.1 version officially support integration with Tungsten Fabric? Reference Material – If supported, could you please suggest any official documentation, blogs, or reference implementations that describe the integration process? Integration Guidance – What would be the recommended approach for integrating TF with Neutron in a Kolla-based deployment? Are there any specific configuration patterns or community best practices we should follow? Necessity – In the context of building a public cloud, is Tungsten Fabric integration considered mandatory for production-grade networking, or can similar functionality be achieved with the default Neutron backends (e.g., OVN/OVS)? We are currently at the early stages of our deployment plan and can make architectural changes before the release. Any guidance, experiences, or resources from the community will be highly valuable for our decision-making process. Thank you in advance for your support. 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."

3 2

[release] Release countdown for week R-7
by Thierry Carrez 08 Aug '25

08 Aug '25

Development Focus ----------------- We are entering the last weeks of the 2025.2 "Flamingo" development cycle. From now until the final release, we'll send a countdown email like this every week. It's probably a good time for teams to take stock of their library and client work that needs to be completed yet. The non-client library freeze is coming up, followed closely by the client lib freeze. Please plan accordingly to avoid any last minute rushes to get key functionality in. General Information ------------------- Next week is the Extra-AC freeze, in preparation for elections. All contributions to OpenStack are valuable, but some are not expressed as Gerrit code changes. Please list active contributors to your project team who do not have a code contribution this cycle, and therefore won't automatically be considered an Active Contributor and allowed to vote. This is done by adding extra-acs to https://opendev.org/openstack/governance/src/branch/master/reference/projec… before the Extra-AC freeze on August 14. A quick reminder of the upcoming freeze dates. Those vary depending on deliverable type: * Oslo libraries are entering feature freeze next week, August 14. * General libraries (except client libraries) need to have their last feature release before Non-client library freeze (August 21). Their stable branches are cut early. * Client libraries (think python-*client libraries) need to have their last feature release before Client library freeze (August 28) * Deliverables following a cycle-with-rc model (that would be most services) observe a Feature freeze on that same date, August 28. Any feature addition beyond that date should be discussed on the mailing list and get PTL approval. After feature freeze, cycle-with-rc deliverables need to produce a first release candidate (and a stable branch) before RC1 deadline (September 12) * Deliverables following cycle-with-intermediary model can release as necessary, but in all cases before Final RC deadline (September 25) Finally, now is also a good time to start planning what highlights you want for your deliverables in the cycle highlights. The deadline to submit an initial version for those is set to one week after Feature freeze (September 4). Background on cycle-highlights: http://lists.openstack.org/pipermail/openstack-dev/2017-December/125613.html Project Team Guide, Cycle-Highlights: https://docs.openstack.org/project-team-guide/release-management.html#cycle… jeremy [at] openstack.org/fungi on IRC is available if you need help selecting or writing your highlights. Upcoming Deadlines & Dates -------------------------- Extra-AC freeze: August 14 (R-7 week) Oslo feature freeze: August 14 (R-7 week) Non-client library freeze: August 21 (R-6 week) Client library freeze: August 28 (R-5 week) Flamingo-3 milestone: August 28 (R-5 week) Cycle highlights deadline: September 4 (R-4 week) OpenInfra Summit Europe: October 17-19, 2025 -- Thierry Carrez (ttx)

1 0

[watcher] Using watcher without standard Openstack telemetry projects
by Laurent Dumont 08 Aug '25

08 Aug '25

Hey folks! I am looking at Watcher for a possible integration with an Openstack cloud where : - The Openstack cloud does not have Gnocchi/Ceilometer or the STF from Red Hat. - I am able to get standard libvirt metrics from a compute. Before going too deep, if we assume that we can expose metrics using an OpenMetric/Prometheus format, can Watcher be fed these metrics? Thanks!

2 1

[neutron] Drivers meeting canceled Friday, August 8th
by Brian Haley 07 Aug '25

07 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

[cinder] 2025.2 Midcycle reminder
by Jon Bernard 07 Aug '25

07 Aug '25

Hello all, this is a reminder that our midcycle/review meeting will take place on Monday August 18th from 1400 to 1600 UTC. The etherpad we'll be using is here [1], please add any topics and review information that you would like to cover. [1]: https://etherpad.opendev.org/p/cinder-flamingo-midcycles -- Jon

1 0

[tc][all][monasca] Retiring the Monasca project and repositories
by Goutham Pacha Ravi 07 Aug '25

07 Aug '25

Hello Stackers, We intend to retire the Monasca project [1] and all associated repositories [2]. The retirement is being proposed with the support and consent of the current core team members and the Project Team Lead (PTL) [3]. For context, the Monasca project team was marked as being inactive during the 2024.1 (Caracal) release cycle [4]. Since then, no sustained development activity has occurred. There have been no releases tagged for any of the deliverables owned by the team either, and there are no actively maintained stable branches. So, in accordance with the procedures in the OpenStack governance documentation [5], and based on the current state of the project, we propose the following repositories ahead of the 2025.2 ("Flamingo") coordinated release: - openstack/monasca-agent - openstack/monasca-api - openstack/monasca-common - openstack/monasca-events-api - openstack/monasca-log-api - openstack/monasca-notification - openstack/monasca-persister - openstack/monasca-specs - openstack/monasca-tempest-plugin - openstack/monasca-thresh - openstack/python-monascaclient - openstack/monasca-ui - openstack/monasca-transform - openstack/monasca-ceilometer - openstack/monasca-grafana-datasource - openstack/monasca-kibana-plugin - openstack/monasca-statsd Some of the current maintainers intend to fork the project and continue development independently for their purposes. This retirement does not preclude such efforts; nor does it prevent reviving the project after the retirement. If there are any objections to retiring the project, please respond to this thread. In the event there is interest in continuing Monasca within OpenStack, we would expect the project team to meet the requirements for active status [6] — including identifying a new PTL for the upcoming release cycle and demonstrating plans for sustained maintenance. Thank you to everyone who has contributed to Monasca over the years. Thanks, On behalf of the OpenStack TC, Goutham Pacha Ravi (gouthamr) OpenStack TC Chair [1] https://docs.openstack.org/monasca-api/latest/ [2] https://github.com/openstack/governance/blob/624bb5bf124452eed475c9b6e62144… [3] https://review.opendev.org/c/openstack/governance/+/953671 [4] https://governance.openstack.org/tc/reference/emerging-technology-and-inact… [5] https://docs.openstack.org/project-team-guide/repository.html#retiring-a-re… [6] https://governance.openstack.org/tc/reference/new-projects-requirements.html

3 2

[dev][designate] PSA: pkg_resources is broken with newer oslo wheels on Python 3.8
by Stephen Finucane 07 Aug '25

07 Aug '25

o/ A quick PSA for a topic has come up in a few different OpenStack forums of late. As described in a recently filed setuptools bug [1], the pkg_resources found in the most recent version of setuptools to support Python 3.8 does not correctly normalize package names passed to `pkg_resources.require`. This has become an issue of late because since earlier this year the OpenStack release tooling has started (correctly) normalizing filenames of the '.whl' files uploaded to PyPI (so e.g. 'oslo.messaging' now becomes 'oslo_messaging'). You are likely to see this manifest with weird errors like `The 'package.foo>=1.2.3' distribution was not found`, when you know that it is. I have seen it pop up because either (a) pkg_resources is being invoked via an explicit call, as in some of the release tooling used in `openstack/releases`, or (b) pkg_resources is being invoked via the auto-generated import headers added by setuptools when you use its legacy "scripts" keyword rather than newer "console scripts" replacement. The latter in particular is biting some projects indirectly due to Designate and Octavia incorrectly using this mechanism to work around the demise of wsgi_scripts, and I have fixes up waiting for review [2][3]. Just sharing in case some people have seen this, because it's quite a weird corner case to hit. Stephen [1] https://github.com/pypa/setuptools/issues/5051 [2] https://review.opendev.org/c/openstack/designate/+/950569/ [3] https://review.opendev.org/c/openstack/designate/+/955683/

3 3

[Kolla][Epoxy] Potentially incorrect Debian backports repo in Epoxy container builds?
by Michael Still 07 Aug '25

07 Aug '25

Hello, yesterday I was having troubles building Kolla images for Epoxy. I'm building Debian based images, and the failures were related to the osbpo extrepo not always returning results. However, I noticed this line as part of that adventure: https://github.com/openstack/kolla/blob/stable/2025.1/docker/base/Dockerfil… Specifically, Kolla for Epoxy is using the Dalmatian extrepo: "extrepo enable openstack_dalmatian" Is this somehow intentional? If not, I'll send a patch to correct it to Epoxy. Thanks, Michael

2 1

Guidance Needed: OpenStack(Kolla Ansible 2023.1) + Ceph Production Deployment with RBD Mirroring
by Thamanna Farhath 06 Aug '25

06 Aug '25

Hi all, I’m working on a production deployment using OpenStack (Kolla Ansible 2023.1) and Ceph (via Ceph Ansible). Setup Overview: One control plane with shared core services. Multiple availability zones (AZs), each as a separate Nova Cell. Each AZ has its own Ceph cluster, connected via RBD mirroring for DC/DR. Architecture diagram is attached below Looking for advice on: Best practices for this architecture. Ceph RBD mirroring impact on Glance, Cinder, Nova. Suggestions for high availability and failover strategies in this design. Appreciate any guidance or references! Thanks & regards Thamanna Farhath N Disclaimer : The content of this email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to which they are addressed. If you have received this email in error, please notify the sender and remove the messages from your system. If you are not the named addressee, it is strictly forbidden for you to share, circulate, distribute or copy any part of this e-mail to any third party without the written consent of the sender. E-mail transmission cannot be guaranteed to be secured or error free as information could be intercepted, corrupted, lost, destroyed, arrive late, incomplete, or may contain viruses. Therefore, we do not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. The recipient should check this e-mail and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email."

1 0

about the server group GET API
by Jiatong Shen 06 Aug '25

06 Aug '25

Hello experts, I have a question about the server group GET rest API. I tried out the GET API and found it was pretty slow (around 200 servers returned in 8 seconds). By skimming through the codebase I am suspecting filtering out group members is heavy ( https://github.com/openstack/nova/blob/4100d4d8fbaa6416ea37d8cb3e64003f40ee… ). So my question is do we clear out the instance_group_member table after deleting instances? If not, why could we not do it? Thank you very much for help. . -- Best Regards, Jiatong Shen

1 0