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

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

07 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 07 Aug '25

07 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

[all][elections][ptl][tc] Combined PTL/TC 2026.1 cycle Election Season
by Slawomir Kaplonski 06 Aug '25

06 Aug '25

Election details: https://governance.openstack.org/election/ The nomination period officially begins Aug 06, 2025 23:45 UTC. Please read the stipulations and timelines for candidates and electorate contained in these governance documents[1][2][3]. Due to circumstances of timing, PTL and TC elections for the coming cycle will run concurrently; deadlines for their nomination and voting activities are synchronized but will still use separate ballots. Please note, if only one candidate is nominated as PTL for a project team during the PTL nomination period, that candidate will win by acclaim, and there will be no poll. There will only be a poll if there is more than one candidate stepping forward for a project team's PTL position. Similarly, there will only be a TC poll if there are more than 4 candidates stepping forward the available TC positions. All members of the community are encouraged to confirm their email address as described at: https://governance.openstack.org/election/#electorate All candidates and prospective voters need to make sure they have reestablished their individual memberships in the OpenInfra Foundation [4], otherwise their nominations won't be verified and ballots will not be sent. There will be further announcements posted to the mailing list as action is required from the electorate or candidates. This email is for information purposes only. If you have any questions which you feel affect others please reply to this email thread. If you have any questions that you wish to discuss in private please email any of the election officials[5] so that we may address your concerns. Thank you, [1] https://governance.openstack.org/tc/reference/charter.html [2] https://governance.openstack.org/tc/reference/role-of-the-tc.html [3] https://docs.openstack.org/project-team-guide/ptl.html [4] https://lists.openinfra.org/archives/list/foundation@lists.openinfra.org/me… [5] https://governance.openstack.org/election/#election-officials -- Best regards Slawek Kaplonski skaplons(a)redhat.com

1 0

[keystone] User Impersonation feature
by Bram Kranendonk 06 Aug '25

06 Aug '25

Hi folks, I’m looking for a way to execute actions using Admin User X for Regular User Y. I came across the OS-TRUST extension with the impersonation flag, but this does not allow for an admin user to create trusts as another trustor. Are there other ways to accomplish such feature in Keystone? Thanks in advance, . Bram Kranendonk OpenStack Engineer

2 1

[openstack-helm] Nominate Doug Goldstein (cardoe) as a core reviewer
by Vladimir Kozhukalov 05 Aug '25

05 Aug '25

Hi team, I am writing to nominate Doug Goldstein (cardoe) as a member of the Openstack-helm core reviewers team. He's been actively contributing to the project during the last few release cycles and brought many valuable ideas (both technical and organizational). I also think it is important that our project has different companies represented in this important role. Please let me know what you think. -- Best regards, Kozhukalov Vladimir

5 5