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

[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