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

[keystone][ops] Upgrade to 2025.1 and "corner cases"
by Dmitriy Rabotyagov 25 Aug '25

25 Aug '25

Hey folks, I wanted to raise awareness of operators regarding Keystone upgrade to Epoxy (2025.1), as found that existing release notes are slightly more vague about corner case definition. During analysis, it appeared that a lot of users (and under "a lot" I mean 4 figures number) in my really old deployments (which were deployed during Newton), still in use passwords hashed with sha512_crypt which has been dropped in 2025.1 [1]. As this was referenced as a "corner case" in upgrade docs, it may not bring enough attention to this matter reading notes, while sha512_crypt removal is mentioned in "Other" section which I personally missed when analyzing upgrade requirements. So I would highly recommend to ensure that all your users are using supported hashing algorithms before the upgrade to Epoxy, and inform them to reset their passwords if they don't. You can list users who are using unsupported hashing algorithm using following MySQL query: SELECT distinct l_u.user_id FROM keystone.local_user AS l_u JOIN keystone.password AS hash ON l_u.id = hash.local_user_id WHERE (hash.password_hash LIKE '$6$%' OR hash.password_hash LIKE '$5$%') AND hash.expires_at i s null; Hope this helps somebody to save some time in the future. [1] https://opendev.org/openstack/keystone/commit/4a4137d5f77ced3f4f011846fb9c2…

2 2

[ops][largescale-sig][scientific-sig] Ops Radio Hour on August 22, 2025
by Ildiko Vancsa 23 Aug '25

23 Aug '25

Hi OpenStack community, I'm reaching out to you with a friendly reminder that the next OpenStack Ops Radio Hour[1] is scheduled to happen on __August 22nd, 2025 at 1300UTC.__ The call series is a casual setting for operators, engineers, and contributors to come together, share knowledge, and collaborate on the complexities of managing and deploying OpenStack environments. Topics the next gathering will dive into: - (SWIFT) Compliance processes - GPUs - VMware migration - vTPM (live migrations or not?): reboot, start - Keystone security param bug - https://bugs.launchpad.net/keystone/+bug/2117217 - Consolidating Ops IRC and Matrix channels What other topics should we add to the agenda? A few reminders: - The group on the call agreed to try out Matrix as a chat platform for more synchronous communication outside calls + You can access the Matrix room here: https://matrix.to/#/#openstack-ops:opendev.org<https://matrix.to/#/%23openstack-ops:opendev.org> + Further details are here: https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack… - If you would like to read and catch up on notes from previous calls, you can find them in this etherpad: https://etherpad.opendev.org/p/openstack_ops_radiohour See you on the call on August 22nd! Bets Regards, Ildikó [1] https://wiki.openstack.org/wiki/Operations/Meetups

1 1

[cinder-backup]cinder backup show progress percentage
by Nguyễn Hữu Khôi 23 Aug '25

23 Aug '25

Hello. I would like to know if we have some methods to show backup progress percentage. I see this but it is old and work only with Swift. https://specs.openstack.org/openstack/cinder-specs/specs/kilo/backup-notifi… Nguyen Huu Khoi

1 0

[freezer]backup with cindernative mode
by Nguyễn Hữu Khôi 23 Aug '25

23 Aug '25

Hello. I am using openstack 2025.1 and freezer 2025.1 to test. I can backup and restore using cinder. but I won't do it with cindernative, could you tell me that we need swiff to use this mode? This is my command: freezer-agent --mode cindernative --cindernative-vol-id fcc22b9f-ef01-4d16-bfde-83af6312bce9 --log-file k.log --debug Critical Error: Endpoint for object-store not found - have you specified a region? Thank much. Nguyen Huu Khoi

2 11

Keystone "TokenNotFound: Failed to validate token"
by Marc Vorwerk 23 Aug '25

23 Aug '25

Hi all, I am running into an issue with our OpenStack Kolla-Ansible deployment (Release 2024.1, Keystone 25.0.1) where Keystone logs are being flooded (18k per day) with TokenNotFound: Failed to validate token stack traces[1]. From the traceback, it seems these requests are attempting to validate tokens that have already been revoked. The majority of these come from Nova and Cinder, but the request_id from Keystone does not appear in their logs. Instead of finding the matching requests in Nova or Cinder logs, I only see InvalidToken: Token authorization failed messages[2]. Most of the time, the platform does not show any user-visible issues in these areas, although occasional failures can be observed. Could this indicate an issue with token caching or revocation list synchronization between services? Memcached looks fine. Any ideas what could be triggering this behavior are welcome. If you need more Information please let me know. Thanks in advance. Best regards, Marc [1] ERROR keystone.server.flask.application [None req-326cbeaa-a363-4a82-b45b-498d6f2ad338 b30e2d031b6a4851b69f9b1791716919 d977f9d63d3043288bed6e549e507c9a - - default default] Failed to validate token: keystone.exception.TokenNotFound: Failed to validate token ERROR keystone.server.flask.application Traceback (most recent call last): ERROR keystone.server.flask.application File "/var/lib/kolla/venv/lib/python3.10/site-packages/flask/app.py", line 870, in full_dispatch_request ERROR keystone.server.flask.application rv = self.dispatch_request() ERROR keystone.server.flask.application File "/var/lib/kolla/venv/lib/python3.10/site-packages/flask/app.py", line 855, in dispatch_request ERROR keystone.server.flask.application return self.ensure_sync(self.view_functions[rule.endpoint])(**view_args) # type: ignore[no-any-return] ERROR keystone.server.flask.application File "/var/lib/kolla/venv/lib/python3.10/site-packages/flask_restful/__init__.py", line 489, in wrapper ERROR keystone.server.flask.application resp = resource(*args, **kwargs) ERROR keystone.server.flask.application File "/var/lib/kolla/venv/lib/python3.10/site-packages/flask/views.py", line 110, in view ERROR keystone.server.flask.application return current_app.ensure_sync(self.dispatch_request)(**kwargs) # type: ignore[no-any-return] ERROR keystone.server.flask.application File "/var/lib/kolla/venv/lib/python3.10/site-packages/flask_restful/__init__.py", line 604, in dispatch_request ERROR keystone.server.flask.application resp = meth(*args, **kwargs) ERROR keystone.server.flask.application File "/var/lib/kolla/venv/lib/python3.10/site-packages/keystone/api/auth.py", line 285, in get ERROR keystone.server.flask.application ENFORCER.enforce_call(action='identity:validate_token') ERROR keystone.server.flask.application File "/var/lib/kolla/venv/lib/python3.10/site-packages/keystone/common/rbac_enforcer/enforcer.py", line 422, in enforce_call ERROR keystone.server.flask.application subj_token_target_data = cls._extract_subject_token_target_data() ERROR keystone.server.flask.application File "/var/lib/kolla/venv/lib/python3.10/site-packages/keystone/common/rbac_enforcer/enforcer.py", line 261, in _extract_subject_token_target_data ERROR keystone.server.flask.application token = PROVIDER_APIS.token_provider_api.validate_token( ERROR keystone.server.flask.application File "/var/lib/kolla/venv/lib/python3.10/site-packages/keystone/common/manager.py", line 110, in wrapped ERROR keystone.server.flask.application __ret_val = __f(*args, **kwargs) ERROR keystone.server.flask.application File "/var/lib/kolla/venv/lib/python3.10/site-packages/keystone/token/provider.py", line 147, in validate_token ERROR keystone.server.flask.application self._is_valid_token(token, window_seconds=window_seconds) ERROR keystone.server.flask.application File "/var/lib/kolla/venv/lib/python3.10/site-packages/keystone/token/provider.py", line 201, in _is_valid_token ERROR keystone.server.flask.application self.check_revocation(token) ERROR keystone.server.flask.application File "/var/lib/kolla/venv/lib/python3.10/site-packages/keystone/common/manager.py", line 110, in wrapped ERROR keystone.server.flask.application __ret_val = __f(*args, **kwargs) ERROR keystone.server.flask.application File "/var/lib/kolla/venv/lib/python3.10/site-packages/keystone/token/provider.py", line 138, in check_revocation ERROR keystone.server.flask.application return self.check_revocation_v3(token_values) ERROR keystone.server.flask.application File "/var/lib/kolla/venv/lib/python3.10/site-packages/keystone/common/manager.py", line 110, in wrapped ERROR keystone.server.flask.application __ret_val = __f(*args, **kwargs) ERROR keystone.server.flask.application File "/var/lib/kolla/venv/lib/python3.10/site-packages/decorator.py", line 232, in fun ERROR keystone.server.flask.application return caller(func, *(extras + args), **kw) ERROR keystone.server.flask.application File "/var/lib/kolla/venv/lib/python3.10/site-packages/dogpile/cache/region.py", line 1632, in get_or_create_for_user_func ERROR keystone.server.flask.application return self.get_or_create( ERROR keystone.server.flask.application File "/var/lib/kolla/venv/lib/python3.10/site-packages/dogpile/cache/region.py", line 1092, in get_or_create ERROR keystone.server.flask.application with Lock( ERROR keystone.server.flask.application File "/var/lib/kolla/venv/lib/python3.10/site-packages/dogpile/lock.py", line 185, in __enter__ ERROR keystone.server.flask.application return self._enter() ERROR keystone.server.flask.application File "/var/lib/kolla/venv/lib/python3.10/site-packages/dogpile/lock.py", line 94, in _enter ERROR keystone.server.flask.application generated = self._enter_create(value, createdtime) ERROR keystone.server.flask.application File "/var/lib/kolla/venv/lib/python3.10/site-packages/dogpile/lock.py", line 178, in _enter_create ERROR keystone.server.flask.application return self.creator() ERROR keystone.server.flask.application File "/var/lib/kolla/venv/lib/python3.10/site-packages/dogpile/cache/region.py", line 1046, in gen_value ERROR keystone.server.flask.application created_value = creator( ERROR keystone.server.flask.application File "/var/lib/kolla/venv/lib/python3.10/site-packages/keystone/token/provider.py", line 134, in check_revocation_v3 ERROR keystone.server.flask.application PROVIDERS.revoke_api.check_token(token_values) ERROR keystone.server.flask.application File "/var/lib/kolla/venv/lib/python3.10/site-packages/keystone/common/manager.py", line 110, in wrapped ERROR keystone.server.flask.application __ret_val = __f(*args, **kwargs) ERROR keystone.server.flask.application File "/var/lib/kolla/venv/lib/python3.10/site-packages/keystone/revoke/core.py", line 137, in check_token ERROR keystone.server.flask.application raise exception.TokenNotFound(_('Failed to validate token')) ERROR keystone.server.flask.application keystone.exception.TokenNotFound: Failed to validate token [2] $ grep f47b3827 */*log nova/nova-api.log: INFO nova.api.openstack.requestlog [None req-f47b3827-9070-4761-a9de-0f8c854ccc93 1f24a1c85bb24bc3aa83a22bc6b9a47e 2f764cefd79544f1959b3743281b072d - - 16cb1fce3b1b4842b3be2fb4e88c5c69 16cb1fce3b1b4842b3be2fb4e88c5c69] 10.70.142.1 "GET /v2.1/servers/72970654-cbaf-4e0e-94e0-70e7ba3e0db4" status: 200 len: 3747 microversion: 2.1 time: 0.104714 nova/nova-api.log: WARNING keystonemiddleware.auth_token [None req-f47b3827-9070-4761-a9de-0f8c854ccc93 1f24a1c85bb24bc3aa83a22bc6b9a47e 2f764cefd79544f1959b3743281b072d - - 16cb1fce3b1b4842b3be2fb4e88c5c69 16cb1fce3b1b4842b3be2fb4e88c5c69] Authorization failed for token: keystonemiddleware.auth_token._exceptions.InvalidToken: Token authorization failed nova/nova-api.log: INFO nova.api.openstack.requestlog [None req-f47b3827-9070-4761-a9de-0f8c854ccc93 1f24a1c85bb24bc3aa83a22bc6b9a47e 2f764cefd79544f1959b3743281b072d - - 16cb1fce3b1b4842b3be2fb4e88c5c69 16cb1fce3b1b4842b3be2fb4e88c5c69] 10.70.142.1 "GET /v2.1/servers/detail?name=shoot--system--mon" status: 401 len: 114 microversion: - time: 0.078451

2 3

[ironic][magnum][tacker][telemetry][venus][vitrage] broken gate on master branch
by Elõd Illés 22 Aug '25

22 Aug '25

Hi teams in $SUBJECT, The release team usually checks the gate health of deliverables that did not have merged patches recently and it seems you have a project with broken gate: https://review.opendev.org/q/topic:release-health-check-flamingo+is:open Could you please check and fix the gate so that we don't release 2025.2 Flamingo with a broken state. Thanks in advance, Előd Illés irc: elodilles @ #openstack-release

3 2

[release] Release countdown for week R-5
by Thierry Carrez 22 Aug '25

22 Aug '25

Development Focus ----------------- We are getting close to the end of the 2025.2 "Flamingo" cycle! Next week on August 28th, 2025 is the Flamingo-3 milestone, also known as feature freeze. It's time to wrap up feature work in the services and their client libraries, and defer features that won't make it to the 2026.1 "Gazpacho" cycle. General Information ------------------- This coming week is the deadline for client libraries: their last feature release needs to happen before "Client library freeze" on August 28th, 2025. Only bugfix 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/… August 28th, 2025 is also the deadline for feature work in all OpenStack deliverables following the cycle-with-rc model. To help those projects produce a first release candidate in time, only bugfixes should be allowed in the master branch beyond this point. Any feature work past that deadline has to be raised as a Feature Freeze Exception (FFE) and approved by the team PTL. Finally, feature freeze is also a good time for submitting a first version of your cycle-highlights. Cycle highlights are the raw data that helps shape what is communicated in press releases and other release activity at the end of the cycle, avoiding direct contacts from marketing folks. See https://docs.openstack.org/project-team-guide/release-management.html#cycle… for more details. Upcoming Deadlines & Dates -------------------------- Flamingo-3 milestone (feature freeze): August 28th, 2025 (R-5 week) RC1 deadline: September 12th, 2025 (R-3 week) Final RC deadline: September 25th, 2025 (R-1 week) 2025.2 "Flamingo" final release: October 1st, 2025 OpenInfra Summit Europe: October 17th-19th, 2025 -- Thierry Carrez (ttx)

1 0

[blazar] Blazar-dashboard contains non-free files (ie: minified Javascripts)
by Thomas Goirand 22 Aug '25

22 Aug '25

Hi, I've been trying to package Blazar, all is already in Debian, but I can't get blazar-dashboard in, because upstream source contains non-free files. Namely: https://github.com/openstack/blazar-dashboard/blob/master/blazar_dashboard/… is a minifed version of a much more complex package: https://github.com/apexcharts/apexcharts.js/tree/v3.31.0 Reminder: minified Javascripts are considered by most distributions (this includes Red Hat, Ubuntu, and in my case Debian) as non-free files that cannot be shipped in the distribution without the underlying source code, and packages must build from the not minified version. Could the Blazar team work on un-vendoring apexcharts.min.js, possibly removing it completely, or replacing it with a source-full version? Cheers, Thomas Goirand (zigo)

4 6

[ops] [all] One Week until 2025 OpenStack User Survey Deadline
by Allison Price 21 Aug '25

21 Aug '25

Hi everyone, I wanted to remind everyone that next Friday, August 29 is the deadline to complete this year’s OpenStack User Survey. If you haven’t taken it before, this is a great opportunity to help channel feedback to the upstream community while helping us understand the global OpenStack footprint better. It should only take ~20 minutes and is incredibly valuable. If you have taken it before, it’s still important to review and update your data. This should only take a few minutes. https://openstack.org/usersurvey Thank you all! Cheers, Allison

1 0

[neutron] Drivers meeting canceled Friday, August 22nd
by Brian Haley 21 Aug '25

21 Aug '25

Hello Neutrinos: I am going to cancel tomorrow's Drivers meetings as there will not be quorum. Just a reminder there are still open specs that need updates and/or review, list is at [0]. Have a nice weekend! -Brian [0] https://review.opendev.org/q/status:open+project:openstack/neutron-specs

1 0

[all] Keeping old unmaintained branches open for longer time, but with no CI, instead of EOL tags
by Thomas Goirand 21 Aug '25

21 Aug '25

Hi, It's our policy that we maintain only a few branches, currently, from Caracal to Epoxy (so, 3 stable branches). Currently, when a Stable branch becomes unsuported, we rename that branch as: unmaintained/2023.1 which is fine, as we can still commit there. Though after some times, the branches are deleted, and instead, we just do a tag such as: zed-EOL Jeremy Stanley just wrote to me on IRC: "workflows, processes and policies are built around many years of an assumption that unused branches will be deleted" Keeping unmaintained branches "has put a lot of additional strain on project maintainers and our systems" (still quoting Jeremy). Though each time there's a new (grave?) security problem, this topic comes back, as we still have no solution for these cases. As a downstream, I still need to write backports for these important patches, sometimes long after the branches are EOL. Red Hat too... While I agree with all what Jeremy told me on IRC, and I don't think we should attempt to maintain the CI for too long (as this takes too much of our time), I still believe we should keep a way to share patches. Downstream (like myself for Debian) run their own CI based on packages, and it's always better if we can share patches. It doesn't have to be with a maintained CI. Just having opened branches would be enough. Your thoughts? Cheers, Thomas Goirand (zigo)

6 6

[all][elections][tc] TC Election Campaigning Kickoff
by Ian Y. Choi 20 Aug '25

20 Aug '25

Developers, The TC Election Campaigning Period has now started[1]. During the next couple days, you are all encouraged to ask the candidates questions about their platforms[2], opinions on OpenStack, community governance, and anything else that will help you to better determine how you will vote. This is the time to raise any issues you wish the future TC to consider, and to evaluate the opinions of the nominees prior to their election. Candidates, Each of you has posted a platform[2], and announced your nomination to the developers. From this point, you are encouraged to ask each other questions about the posted platforms, and begin discussion of any points that you feel are particularly important during the next cycle. While you are not yet TC members, your voices and opinions about the issues raised in your platforms and questions raised by the wider community will help ensure that the future TC has the widest possible input on the matters of community concern, and the electorate has the best information to determine the ideal TC composition to address these and other issues that may arise. [1] https://governance.openstack.org/election/ [2] https://opendev.org/openstack/election/src/branch/master/candidates/2026.1/… Ian Y. Choi & Slawek Kaplonski, on behalf of election officials.

1 0

[all][elections][ptl][tc] Combined PTL/TC 2026.1 cycle Election Nominations End
by Ian Y. Choi 20 Aug '25

20 Aug '25

The PTL and TC Nomination period is now over. The official candidate lists for PTLs [0] and TC seats [1] are available on the election website. -- PTL Election Details -- There are 4 projects without candidates, so according to this resolution[2], the TC will have to decide how the following projects will proceed: Monasca, OpenStack_Charms, Venus, Vitrage There are 1 project that will have elections: Horizon. -- TC Election Details -- The official candidate list is available on the election website[1]. Now begins the campaigning period where candidates and electorate may debate their statements. Polling will start Aug 27, 2025 23:45 UTC. Thank you, [0] https://governance.openstack.org/election/#ptl-candidates [1] https://governance.openstack.org/election/#tc-candidates [2] https://governance.openstack.org/resolutions/20141128-elections-process-for…

1 0

OSSN-0094: Ensuring Volume Safety with Nova and Watcher
by Jay Faulkner 20 Aug '25

20 Aug '25

OSSN-0094: Ensuring Volume Safety with Nova and Watcher == Summary == A vulnerability has been identified in OpenStack Nova and OpenStack Watcher in conjunction with volume swap operations performed by the Watcher service. Under specific circumstances, this can lead to a situation where two Nova libvirt instances could reference the same block device, allowing accidental information disclosure to the unauthorized instance. == Affected Services / Software == Services: Nova,Watcher Releases: all supported releases == Discussion == The issue occurs when Watcher's zone migration strategy performs the following sequence of events: 1. Watcher initiates a volume swap using Nova's internal-only volume swap API 2. Watcher initiates a live migration of the same instance 3. In some error cases connection details may have failed to update storage references. These invalid details are used during the live migration. === Required Access === The swap volume, live migration and all Watcher APIs are admin only so with default policy is only possible to create the inconsistent state described in this OSSN if you have admin rights on the relevant OpenStack project. === Further Watcher Hardening === The Watcher service, when first created, often implemented its own means to perform operations. Many of those operations can now be done natively via other OpenStack services. In the specific context of OSSN-0094, the ability to migrate Cinder volumes between storage backends is such an example. Additionally, the Cinder volume migration in Watcher created a new Keystone user with the admin role assigned for the instance owners' project and then used that user to perform API requests on behalf of the project. This code has been removed. Finally, due to limited error handling and no validation that the objects involved were migrated properly, some error scenarios could have led to a source volume being deleted despite not having been migrated properly. === Resolution === Nova will now reject any request to swap a volume that has an empty migration status, effectively restricting the usage of this API to Cinder. This brings the API validation in line with the documentation. Watchers internal implementation of swap volume has been deleted and updated to use Cinder's native volume migration as a replacement. Watcher no longer creates temporary Keystone users in normal operation. === Patches === Patches for Nova and Watcher have been backported to all supported stable branches and committed to master branch. stable/2025.1: * Watcher: https://review.opendev.org/c/openstack/watcher/+/957770 * Nova: https://review.opendev.org/c/openstack/nova/+/957759 stable/2024.2: * Watcher: https://review.opendev.org/c/openstack/watcher/+/957773 * Nova: https://review.opendev.org/c/openstack/nova/+/957762 stable/2024.1: * Watcher: https://review.opendev.org/c/openstack/watcher/+/957774 * Nova: https://review.opendev.org/c/openstack/nova/+/957764 == Recommended Actions == * Operators using Watcher's zone migration strategy should apply the provided Watcher and Nova patches as soon as possible. * Operators should refrain from using the swap volume migration action in Watcher. The compatibility code for swap volume that uses a Cinder-based migration may be removed in a future API version. * Operators should audit all users with the admin role and ensure no temporary Watcher-created users remain. * Operators using custom policy for volume attachment (''/servers/{server_id}/os-volume_attachments/{volume_id}'') or live migration API should review the state of existing instances which have had volume migrations. Any instance in an inconsistent state can be resolved by hard rebooting the instance using Nova's API. == Contacts / References == * Author: Sean Mooney <smooney(a)redhat.com>, Jay Faulkner <jay(a)jvf.cc> * This OSSN : https://wiki.openstack.org/wiki/OSSN/OSSN-0094 * Original LaunchPad Bug : https://bugs.launchpad.net/nova/+bug/2112187 * Mailing List : [Security] tag on openstack-discuss(a)lists.openstack.org * OpenStack Security Project : https://launchpad.net/~openstack-ossg * CVE: None

1 0

[vitrage][tc] Project status
by Takashi Kajinami 20 Aug '25

20 Aug '25

Hi, Some of you might be aware of this, but tempest jobs in vitrage repo have been broken for some time (I remember I saw consistent failures early in this cycle and I'm afraid that the situation hasn't been improved.) I spent some time to dig into these failures and found out a few problems. However I'm afraid I can't fix these all with my limited knowledge about vitrage. # I've helped its project maintenance for some time but I've never looked into # its implementations quite in detail. So I'm sharing my observations here hoping someone who know better about it can look into these. 1. Usage of removed oslo_context.context.RequestContext interfaces This is the most trivial and can be fixed easily. https://review.opendev.org/c/openstack/vitrage/+/957004/2/vitrage/api/hooks… 2. Usage of asyncore modules from pysnmp-lextudio Recent release of pysnmp-lextudio no longer provides these modules, likely due to removal of asyncore in Python 3.12 . I was drafting the migration to asyncio version in https://review.opendev.org/c/openstack/vitrage/+/957004 but learned simple replacement does not work and we need more careful assessment. This might be the most tricky problem atm. 3. Some tempest test failures I can no longer see old CI results, but as far as I'm aware, CI jobs were blocked by a few tests consistently failing early in this cycle so we may have to dig into these, too. You may find some tempest tests failures in https://review.opendev.org/c/openstack/vitrage/+/957004 though I'm unsure if these are related to broken snmp service, which is caused by incomplete migration to asyncio (which I described in 2). I'm adding the tc tag, to notify them of the current status. Thank you, Takashi Kajinami -- Takashi Kajinami irc: tkajinam github: https://github.com/kajinamit launchpad: https://launchpad.net/~kajinamit

2 2

[swift] Unmaintained branch cleanup
by Tim Burke 20 Aug '25

20 Aug '25

Swift currently has six unmaintained branches: - unmaintained/2023.1 - unmaintained/zed - unmaintained/yoga - unmaintained/xena - unmaintained/wallaby - unmaintained/victoria Half of them have not been updated this year. For all of them, the only patches since the transition to unmaintained status were to try to maintain CI. While two of them have open patches, they all seem to revolve around maintaining CI and none of them currently pass. I propose transitioning all of these to end-of-life. If you have any objections, please respond here on the mailing list or at https://review.opendev.org/c/openstack/releases/+/958101 which makes the change. Tim

1 0

[horizon] Today's weekly meeting is cancelled
by Tatiana Ovchinnikova 20 Aug '25

20 Aug '25

Hello team, A reminder that today's meeting is cancelled since more than a half of the team is busy with downstream activities. With kind regards, Tatiana

1 0

[masakari] Add a rpc api for ping check
by do-gyun kim 20 Aug '25

20 Aug '25

Similar to Nova, I think it would be good to add ping api to masakari engine for rpc health check. This can be used for reading business and lifestyle check in Masakari distributed to Kubernetes through OpenStack Helm. Currently, there is no health check for masakari-engine in openstack-helm project, but it would be good to add it. Blueprint: https://blueprints.launchpad.net/masakari/+spec/add-a-rpc-api-for-ping

1 1

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

19 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 : 1 day, 9:36:15 Nominations progress : 90.00% --------------------------------------------------- Projects[1] : 38 Projects with candidates : 18 ( 47.37%) Projects with election : 1 ( 2.63%) --------------------------------------------------- Need election : 1 (Horizon) Need appointment : 20 (Adjutant Barbican Blazar Cloudkitty Cyborg Glance Magnum Manila Masakari Mistral Monasca OpenStackAnsible OpenStack_Ch arms Quality_Assurance Rally Swift Tacker Trove Venus Vitrage) --------------------------------------------------- TC Candidates : 2 (4 Required) =================================================== Stats gathered @ 2025-08-19 14:08:45 UTC This means that with approximately 2 days left, 20 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

2 1

[election][cloudkitty] PTL candidacy for the 2026.1 release cycle
by Rafael Weingärtner 19 Aug '25

19 Aug '25

Hi all, I would like to self-nominate for the role of PTL of CloudKitty for the 2026.1 release cycle. I have been PTL since the Victoria cycle and I am willing to continue in this role. I will keep working with existing contributors to maintain CloudKitty for their use cases and encourage the addition of new functionalities. I have opened the patch with my candidacy: https://review.opendev.org/c/openstack/election/+/957871 -- Rafael Weingärtner

1 0

[openstack-client|keystone] API calling behavior for fetching by id or name
by Niklas Schwarz 19 Aug '25

19 Aug '25

Hey there I have observed that the keystone logs are flooded with error messages and a stack trace that resources are not found. When investigating on the issue I noticed that the resources do exist but the behavior of the openstack-client is a bit confusing. I will describe the behavior for the openstack-client in the interaction with the kestone api. As know the openstack-cli which uses the openstack-client has the functionality to show a user either by passing an id or the name of the user. The requests when executing the command with the name of the user will be 1. v3/user/<name_or_id> - v3/user?name=<name_or_id> The first request is issued to the endpoint which expects the rout parameter to be an id of the user and in the case of the keystone api a db query is executed with the name as an id and no user will be found which results in the log message and the stack trace in the keyston logs. Because no user was found the openstack-client issues a second request to the api with the name as a query-parameter instead of a rout-parameter which will issue the db-query at the keystone api to search by the username. On some deployments this can and will be additional load on the database and on the api which can be reduced just by sending the correct request to the api instead of "guessing" and trying for the correct request and hoping there will be an answer. The issue with keystone is that the openstack-client will issue also requests to the keystone api when listing, e.g. networks but only for a specific project (openstack network list --project <name_or_id>). The client will first search for the project and in the worst case these are two requests. In my opinion this behavior can be prevented to send multiple requests to the keystone api (or any other api), either by checking on the client if a the passed parameter is an id or by handling the passed route-parameter accordingly in the keystone api and executing the correct db-query to prevent multiple requests. I have decided on implementing a change [1] on the client side and have adjusted the openstack-client. As artem pointed out in the review that in some services there are places where the id cannot be really identified as such I wanted to ask/I was asked to discuss the issue on the mailing list since there might be multiple projects involved in such a change to reduce the calls to the api (when handling on the client side) or db (when handling on the server side) when a search by an id or name is issued. Are there an plans on tackling this issue or any other options and opinions? The post by marc [2] might also be a result of the openstack-client issuing multiple requests to the api and polluting the logs. So in some cases this is a realy issue. Best regards Niklas [1] https://review.opendev.org/c/openstack/python-openstackclient/+/933644 [2] https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack…

3 4

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

18 Aug '25

Hello Stackers, We're six weeks away from the release date for the 2025.2 "Flamingo" release [1]. We will observe a feature freeze for this release on August 28th. Nominations for TC and PTL elections are due by August 20th at 23:45 UTC [2]. Please remember that you must be a member of the OpenInfra Foundation to contest these elections. The OIF's recent move under the Linux Foundation meant that any prior member is not automatically considered a member unless they accept this change by renewing their membership [3]. To run as a Project Team Lead, one must also have contributed to the project in the one-year period prior to the nomination deadline. We check this by matching the data between the candidate's OIF profile and their contributions on Gerrit. I understand that several well-meaning candidacies could hit roadblocks because of these requirements. We'd be happy to respond to concerns in the #openstack-election channel on OFTC. Ghanshyam Maan (gmaan), a long-serving member of the TC, would like to take a break and will not be contesting the upcoming elections. I'd like to thank him for his many years of service on the TC, including as its chair. I'm excited to see other community members step up to join the TC in his stead. In the past week, the OpenStack Technical Committee worked with several project teams (Oslo, Requirements, Release Management, Freezer, and Ironic) to reaffirm their distributed leadership model and confirm their liaisons for the upcoming release. We also made some progress on retiring repositories owned by the Monasca project team. The governance proposal [4] to that effect is under the community's review. The community is requested to review the proposed runtime (Python versions and Linux distributions) update for the Gazpacho/2026.1 release cycle [5]. === Weekly Meeting === The last weekly meeting of the OpenStack Technical Committee was hosted in OFTC's #openstack-tc channel on August 12th, 2025 [6]. We checked on the progress of retiring the Monasca project team. We also discussed the retirement of the refstack-server in the opendev namespace, noting that while the server has been deleted, a desire remains within the community for a lightweight "certification" process to promote interoperability among providers. However, no one has yet committed to leading this effort. If you're reading this and are interested in working on this, please chime in on this list, or within the #openstack-tc IRC channel on OFTC. The conversation then shifted to the health of the gate and the future supported runtimes [5]. Infra administrators noted that the OpenMetal provider is back online in Zuul and that they are working on adding Debian Trixie and dropping older content like Xenial. As for the runtime for Gazpacho, there was a detailed discussion about dropping Python 3.10 and Ubuntu 22.04, with a consensus to drop the latter but a more cautious approach to Python 3.10, which will remain a minimum supported version for now. The group also agreed to include Python 3.13 as a maximum supported version, as recent bug fixes in eventlet make it viable for testing. The next meeting of the TC is today, August 19th, 2025, at 1700 UTC. This meeting will be hosted over IRC, in OFTC's #openstack-tc channel. Please find the meeting's agenda in the wiki [7]. I hope you'll be able to join us. === Governance Proposals === ==== Open For Review ==== - Reset watcher project leadership from DPL back to PTL | https://review.opendev.org/c/openstack/governance/+/956913 - Require declaration of affiliation from TC Candidates | https://review.opendev.org/c/openstack/governance/+/949432 - Define testing runtime for 2026.1 release | https://review.opendev.org/c/openstack/governance/+/957199 - Retire Monasca project | https://review.opendev.org/c/openstack/governance/+/953671 === 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-09-09: OIF Board Monthly meeting: https://board.openinfra.org/ - 2025-10-17: OpenInfra Summit, Paris-Saclay: https://summit2025.openinfra.org/ 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] Contesting elections: https://governance.openstack.org/election/#how-to-submit-a-candidacy [3] Renew OIF membership: https://openinfra.org/a/renew-membership [4] Retiring Monasca: https://review.opendev.org/c/openstack/governance/+/953671 [5] Runtime update for 2026.1: https://review.opendev.org/c/openstack/governance/+/957199 [6] TC Meeting IRC Log, Aug 12th 2025: https://meetings.opendev.org/meetings/tc/2025/tc.2025-08-12-17.00.html [7] TC Meeting Agenda, Aug 19th 2025: https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Next_Meeting

1 0

[openstack]backup as a service
by Nguyễn Hữu Khôi 18 Aug '25

18 Aug '25

Hello. I am curious that why dont have a complete backup solution for Openstack. I used Cinder backup but It cannot schedule time to backup and wont display how long to complete backup. I found Freezer and Raksha but it was abadonned. Currently, we use Ceph and do snapshot and rbd export to backup Ceph volumes. Nguyen Huu Khoi

2 11

[dev][infra][qa][tact-sig] Updating Zuul to Ansible 11
by Jeremy Stanley 18 Aug '25

18 Aug '25

Just a heads up for those not following OpenDev's service-announce mailing list, today OpenDev is switching Zuul's default Ansible version in the openstack tenant from 9 to 11. See this announcement for further details: https://lists.opendev.org/archives/list/service-announce@lists.opendev.org/… If you notice any new behavior changes in your jobs, double-check that it's not related to the Ansible version update. -- Jeremy Stanley

1 0

[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 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

[nova] Nova API call duration increases after upgrading to Caracal
by Chang Xue 15 Aug '25

15 Aug '25

Hello, we recently upgraded from Bobcat to Caracal. After upgrading, an interesting increment of duration of nova api call is observed. It's involved to multiple API calls, e.g. os-query-sets, /v2.1/servers/detail, etc. And it seems to be accumulated, meaning whenever nova-api is restarted, the duration seems to be fairly fast, giving response within like 80, 90 ms. As it keeps running for like up to 10 days, the duration increases to over 500 ms. I noticed that Caracal is using UnifiedLimitsDriver instead of DbQuotaDriver. I tried to change nova.conf to use DbQuotaDriver but it seems not working well with reducing the duration. I understand that calling to Keystone and Placement (and likely other external APIs) could result to longer duration, but pretty confused why it shows up as accumulated. Wondering if anyone else in Openstack community noticed the similar issue, thanks!

5 10

[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

[ironic] Future of Metalsmith
by Jay Faulkner 14 Aug '25

14 Aug '25

For almost two years, the Ironic team has had a "maintenance mode" message on the Metalsmith readme: "Please note the Metalsmith project is in maintenance mode and it's functionality is slowly being introduced into Ironic's API and usual clients. No additional features are expected to be added to Metalsmith directly." CI is currently not passing on this repository, and as far as I can tell there are no engaged users of this project upstream, and no current maintainers of Ironic invested in keeping this project afloat. I propose we retire the metalsmith project and exclude it from the Flamingo release. Are there any objections? Thanks, JayF

3 2

[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

[cinder] IBM SVf driver callhome
by Vivek Pandey 13 Aug '25

13 Aug '25

Hi Joe/ Brian, Since we didn’t get a chance to discuss the patch [IBM SVf driver] Adding support for callhome plugin, we can continue the conversation here. Patch : https://review.opendev.org/c/openstack/cinder/+/951829. We need callhome enabled as default for which we have introduced a parameter “callhome” in cinder.conf. This feature is to fecth the os_version, cinder-manage version and ispbhaenabled. Note: We are not fetching any customer’s sensitive data. Please let me know if you’ve had a chance to review NetApp’s ActiveIQ implementation. Netapp’s ActiveIQ code ref : https://github.com/openstack/cinder/blob/master/cinder/volume/drivers/netap… As we have discussed during the 9th July cinder call, Anoop from NetApp confirmed that they are enabling it by default and EMS details are being captured from the logs. Based on that, do you think we can align or extend our current IBM callhome implementation (from the patch above) to follow a similar approach? Thanks, Vivek

5 7

[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

[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

[all][ops][qa] Decommissioning RefStack and retiring related software
by Jeremy Stanley 05 Aug '25

05 Aug '25

The RefStack service at refstack.openstack.org has been unused for purposes of qualifying OpenStack trademark licenses[*] since March of last year, after a 2023 board resolution[**] relaxed the former requirement for it. Effective immediately, the service is being decommissioned along with any associated resources, and the related Git repositories in OpenDev (interop, refstack, refstack-client) will be officially retired in the near future as well. Let me know if you have any questions or concerns. [*] https://openinfra.org/legal/trademark-policy [**] https://board.openinfra.org/meetings/minutes/05122023BoardMinutes -- Jeremy Stanley on behalf of the OpenInfra Foundation

4 3

[openstack-helm] GitOps Compatibility with ArgoCD
by aravindh.murugesan＠protonmail.com 05 Aug '25

05 Aug '25

Hello everyone, Hope you're all doing well. I’ve recently started exploring OpenStack-Helm to evaluate its suitability for our long-term needs, and one of the key aspects we’re considering is GitOps integration. While testing a deployment of the Keystone chart using ArgoCD, I noticed that the init container for Keystone waits for certain jobs (like db-init and bootstrap) to complete. However, ArgoCD doesn’t seem to trigger these jobs as expected—likely because it’s still waiting for the pods to become ready. I came across earlier discussions from Doug and Vlad around this topic during a previous PTG, but I wanted to bring it up again in case there have been any updates or ideas on making OpenStack-Helm charts more compatible with GitOps tools like ArgoCD or Flux. I really appreciate the effort and time that this community puts into maintaining and improving these charts. Any guidance or suggestions on how we might adapt this workflow would be incredibly helpful. Thanks so much in advance! Best regards, Aravindh

1 0

[kolla][barbican] Secure password management in Kolla-Ansible using Castellan
by elnazcloud＠gmail.com 05 Aug '25

05 Aug '25

Hi all, I have deployed an OpenStack environment using Kolla Ansible. I'm looking for a way to avoid storing service passwords (e.g., database, keystone, etc.) in clear text inside the configuration files. Is there any recommended method to integrate Barbican and Castellan so that services like Nova, Keystone, or Cinder can fetch secrets securely during runtime using oslo.config? If not natively supported, are there best practices or known workarounds for achieving this securely in a Kolla-based deployment? Thanks in advance!

7 12

[Zed][Neutron][OVN] Severe VM Network Performance Degradation Compared to Host
by Jeff Yang 05 Aug '25

05 Aug '25

Hi all, I'm running OpenStack Zed with OVN as the Neutron backend. I've encountered a severe VM network performance degradation issue and would appreciate any insights from the community. 🔹 **Environment** - OpenStack version: Zed - Neutron backend: OVN - Two VMs (each 4 vCPUs, 8 GB RAM) launched on two different compute nodes - Multi-queue is enabled on the VM vNICs 🔹 **Issue** The network performance inside the VMs is significantly worse than on the host nodes, with high packet retransmissions observed. 🔹 **Test results** **Host-to-Host (VTEP IPs)** ``` $ iperf3 -c 192.168.152.152 Connecting to host 192.168.152.152, port 5201 [ 5] local 192.168.152.153 port 45352 connected to 192.168.152.152 port 5201 [ ID] Interval Transfer Bitrate Retr Cwnd [ 5] 0.00-1.00 sec 1.38 GBytes 11.8 Gbits/sec 0 3.10 MBytes [ 5] 1.00-2.00 sec 1.37 GBytes 11.8 Gbits/sec 0 3.10 MBytes [ 5] 2.00-3.00 sec 1.42 GBytes 12.2 Gbits/sec 0 3.10 MBytes [ 5] 3.00-4.00 sec 1.39 GBytes 11.9 Gbits/sec 0 3.10 MBytes [ 5] 4.00-5.00 sec 1.38 GBytes 11.8 Gbits/sec 0 3.10 MBytes [ 5] 5.00-6.00 sec 1.43 GBytes 12.3 Gbits/sec 0 3.10 MBytes [ 5] 6.00-7.00 sec 1.41 GBytes 12.1 Gbits/sec 0 3.10 MBytes [ 5] 7.00-8.00 sec 1.41 GBytes 12.1 Gbits/sec 0 3.10 MBytes [ 5] 8.00-9.00 sec 1.41 GBytes 12.1 Gbits/sec 0 3.10 MBytes [ 5] 9.00-10.00 sec 1.42 GBytes 12.2 Gbits/sec 0 3.10 MBytes - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate Retr [ 5] 0.00-10.00 sec 14.0 GBytes 12.0 Gbits/sec 0 sender [ 5] 0.00-10.04 sec 14.0 GBytes 12.0 Gbits/sec receiver iperf Done. ``` **VM-to-VM (through overlay network)** ``` $ iperf3 -c 10.0.6.10 Connecting to host 10.0.6.10, port 5201 [ 5] local 10.0.6.37 port 56710 connected to 10.0.6.10 port 5201 [ ID] Interval Transfer Bitrate Retr Cwnd [ 5] 0.00-1.00 sec 499 MBytes 4.19 Gbits/sec 263 463 KBytes [ 5] 1.00-2.00 sec 483 MBytes 4.05 Gbits/sec 467 367 KBytes [ 5] 2.00-3.00 sec 482 MBytes 4.05 Gbits/sec 491 386 KBytes [ 5] 3.00-4.00 sec 483 MBytes 4.05 Gbits/sec 661 381 KBytes [ 5] 4.00-5.00 sec 472 MBytes 3.95 Gbits/sec 430 391 KBytes [ 5] 5.00-6.00 sec 480 MBytes 4.03 Gbits/sec 474 350 KBytes [ 5] 6.00-7.00 sec 510 MBytes 4.28 Gbits/sec 567 474 KBytes [ 5] 7.00-8.00 sec 521 MBytes 4.37 Gbits/sec 565 387 KBytes [ 5] 8.00-9.00 sec 509 MBytes 4.27 Gbits/sec 632 483 KBytes [ 5] 9.00-10.00 sec 514 MBytes 4.30 Gbits/sec 555 495 KBytes - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate Retr [ 5] 0.00-10.00 sec 4.84 GBytes 4.15 Gbits/sec 5105 sender [ 5] 0.00-10.05 sec 4.84 GBytes 4.14 Gbits/sec receiver iperf Done. ``` As you can see, there's a sharp drop in performance inside the VMs (from ~12 Gbps down to ~4 Gbps), with a lot of retransmissions in 10 seconds. Has anyone encountered a similar issue with OVN and VM networking performance? What could be the potential causes? Any suggestions or debugging tips are welcome. Thanks in advance! Best regards,

5 4

[openstack-ansible] Linux bridge support
by Rambo Rambo 05 Aug '25

05 Aug '25

Hi Team We are currently having openstack-ansible Antelope (2023.1) release and have linux bridge currently. We are planning SLUP upgrades from Antelope to Caracal, and than from Caracal to Epoxy. Please confirm if we can still use linux bridge and continue with the upgrades or we need to mandatory move away from linux bridge as linux bridge is now experimental feature before doing the upgrades. We are planning to move away from linux bridge after upgrading to Epoxy release. Please let me know potential issues that can arise with this plan. Regards Rambo

3 2

[neutron] Bug Deputy Report July 28 - Aug 03
by Yatin Karel 05 Aug '25

05 Aug '25

Hi Neutrinos, Below is the bug deputy report for last week:- High ==== - https://bugs.launchpad.net/neutron/+bug/2119097 - [OVN] The OVN agent "metadata" extension is registering the OVN Metadata agent tags Assigned to Rodolfo Alonso - Fix Released - https://bugs.launchpad.net/neutron/+bug/2119092 - [OVN] The ``SbGlobalUpdateEvent`` event in the OVN agent should implement LP#1991817 Assigned to Rodolfo Alonso - Fix Released - https://bugs.launchpad.net/neutron/+bug/2119453 - [FT][master] test_ovs_and_ovs_events fails randomly Unassigned Medium ====== https://bugs.launchpad.net/neutron/+bug/2119093 - [OVN] The ``OVNExtensionEvent`` class is hardcoded to work only with the "metadata" extension Assigned to Rodolfo Alonso - Fix Released Invalid ===== https://bugs.launchpad.net/neutron/+bug/2119294 - [Caracal][DNSaaS] - dns_domain is empty in port show Was related to mis configurations -- Thanks and Regards Yatin Karel

1 0

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

04 Aug '25

Hello Stackers, We're eight weeks away from wrapping up the 2025.2 "Flamingo" release, and three weeks away from its feature freeze (August 28, 2025) [1]. Over the past week, no new governance changes were merged, but some new changes are undergoing community review. The nomination window for Project Team Leads and for four seats on the OpenStack Technical Committee begins on August 6, 2025 [2]. If you have any questions about the process, please post them on this mailing list or hop into #openstack-tc, #openstack-election, or #openstack-dev on OFTC and let's chat. This week, the TC is also looking to refresh the liaisons for projects governed by the "distributed-project-leadership" model—an opportunity for those teams to switch their governance styles, as well. === Weekly Meeting === The TC's weekly meeting focused on two major topics [3]: finalizing the definition of “affiliation” for TC election candidates and the next steps for retiring Monasca. On the affiliation front, we debated whether to reuse the OpenInfra bylaws language or simplify it for our needs. During the meeting, there was a consensus that the definition should focus on contributor intent and a visible employee-employer relationship without getting bogged down in legal technicalities. It's important to share our biases upfront for the sake of transparency and to strive toward the TC's affiliation diversity requirement. We are moving ahead with retiring the Monasca project. After earlier signals of interest in continuing maintenance, the project team now seems comfortable with retirement. The TC consulted this mailing list [4] to seek any further interest in the project. We'll work with the "unmaintained-core" group to clean up deliverables and code branches. We also touched on CI work to test OpenStack with Debian Bookworm and Trixie, which will help us make progress on the Eventlet removal community goal. Finally, a brief discussion ensued on OpenStack for AI, encouraging folks with architectural insight to join the Foundation's AI working group and its mailing list [5]. We wrapped with a shout out to the i18n interns and mentors for their recent progress [6]. The next weekly meeting of the TC is today, August 5, 2025, at 1700 UTC. This meeting will be hosted simultaneously over Meetpad and IRC. Please find the meeting's agenda and call details in the wiki [7]. I hope you'll be able to join us. === Governance Proposals === ==== Open for review ==== - Define "affiliation" within the context of the TC | https://review.opendev.org/c/openstack/governance/+/956024 - Add series names to runtimes doc | https://review.opendev.org/c/openstack/governance/+/955810 - Remove Monasca from active project | https://review.opendev.org/c/openstack/governance/+/953671 - os-test-images never releases | https://review.opendev.org/c/openstack/governance/+/954249 - Require declaration of affiliation from TC Candidates | https://review.opendev.org/c/openstack/governance/+/949432 === Upcoming Events === - 2025-08-06: Nominations open for OpenStack elections: https://governance.openstack.org/election/ - 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/ 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://governance.openstack.org/election/ [3] TC Meeting IRC Log 2025-07-29: https://meetings.opendev.org/meetings/tc/2025/tc.2025-07-29-17.00.html [4] Call for maintainers for Monasca: https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack… [5] OpenInfra AI WG List: https://lists.openinfra.org/mailman3/lists/ai-openstack-wg.lists.openinfra.… [6] i18n Internship with CMU: https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack… [7] TC Meeting Agenda, 2025-08-05: https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Next_Meeting

1 0

[qa] Proposing Sean and Tosky to Devstack core
by Ghanshyam Maan 01 Aug '25

01 Aug '25

Hello Everyone, I would like to propose adding sean-k-mooney and tosky to Devstack core team. Both have shown great knowledge and have been engaged with Devstack for a long time. Having them in the core group would help us to continue maintaining Devstack. Feel free to provide your thoughts. If there are no objections by next week, I plan to add them to the Gerrit group by Friday, August 8th. -gmaan

2 1

[Cinder] Cinder NetApp driver not working as expected on NVMe over TCP
by Vincent Godin 01 Aug '25

01 Aug '25

Hello, We have NetApp C800 arrays for our OpenStack. We have set up the Cinder configuration to use the "NVMe over TCP" protocol. We are currently seeing the following issue: - the volumes (namespaces) are correctly mounted on the hypervisors - the multipath (native) configuration is correctly handled by Cinder (this can be seen in the logs) - the volumes are only attached by a single path Looking at the NetApp driver code, and more specifically at the *nvme_library.py* file and the *initialize_connection* function, we find on line 724: portal = (target_portals[0], self.NVME_PORT, self.NVME_TRANSPORT) data = { "target_nqn": str(target_nqn), "host_nqn": host_nqn, "portals": [portal], "vol_uuid": namespace_uuid } conn_info = {"driver_volume_type": "nvmeof", "data": data} If we look at the values of the target_portals[ ], the array does indeed have all the paths available for the targeted subsystem. However, the function only returns the first path : target_portals[0] I'm not a developer, so I can't guarantee that this is the cause of the problems encountered. What is certain is that manually connecting the namespace with the nvme command does indeed yield all four paths. I'll leave the existing discussion thread that led me to this observation open. Thank you. ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ Vincent Godin <vince.mlist(a)gmail.com> 29 juil. 2025 15:53 (il y a 3 jours) À Rajat, Sean, openstack-discuss Hello, Here are some of the results on the host. An instance is launched by Openstack on the compute nvme list Node Generic SN Model Namespace Usage Format FW Rev --------------------- --------------------- -------------------- ---------------------------------------- ---------- -------------------------- ---------------- -------- /dev/nvme0n1 /dev/ng0n1 81O3QJXiLzBDAAAAAAAH NetApp ONTAP Controller 0x2 16.11 GB / 16.11 GB 4 KiB + 0 B FFFFFFFF if we have a look in the subsystem nvme list-subsys nvme-subsys0 - NQN=nqn.1992-08.com.netapp:sn.ec2c63655c3d11f0a40ad039eaba99f2:subsystem.openstack-79f1de4a-6645-4b47-9377-f06db6c2e0b5 hostnqn=nqn.2014-08.org.nvmexpress:uuid:629788a4-04c6-547c-9121-8d7a39c17fe9 iopolicy=round-robin \ +- nvme0 tcp traddr=10.10.184.3,trsvcid=4420,src_addr=10.10.184.33 live I have only one path I disconnect the subsystem manually nvme disconnect -n nqn.1992-08.com.netapp:sn.ec2c63655c3d11f0a40ad039eaba99f2:subsystem.openstack-79f1de4a-6645-4b47-9377-f06db6c2e0b5 NQN:nqn.1992-08.com.netapp:sn.ec2c63655c3d11f0a40ad039eaba99f2:subsystem.openstack-79f1de4a-6645-4b47-9377-f06db6c2e0b5 disconnected 1 controller(s) I reconnect to the subsystem with a manual command nvme connect-all -t tcp -a 10.10.186.3 nvme list Node Generic SN Model Namespace Usage Format FW Rev --------------------- --------------------- -------------------- ---------------------------------------- ---------- -------------------------- ---------------- -------- /dev/nvme0n2 /dev/ng0n2 81O3QJXiLzBDAAAAAAAH NetApp ONTAP Controller 0x2 16.11 GB / 16.11 GB 4 KiB + 0 B FFFFFFFF And if we look at the subsystem nvme list-subsys nvme-subsys0 - NQN=nqn.1992-08.com.netapp:sn.ec2c63655c3d11f0a40ad039eaba99f2:subsystem.openstack-79f1de4a-6645-4b47-9377-f06db6c2e0b5 hostnqn=nqn.2014-08.org.nvmexpress:uuid:629788a4-04c6-547c-9121-8d7a39c17fe9 iopolicy=round-robin \ +- nvme5 tcp traddr=10.10.184.3,trsvcid=4420,src_addr=10.10.184.33 live +- nvme4 tcp traddr=10.10.186.3,trsvcid=4420,src_addr=10.10.186.33 live +- nvme3 tcp traddr=10.10.184.4,trsvcid=4420,src_addr=10.10.184.33 live +- nvme2 tcp traddr=10.10.186.4,trsvcid=4420,src_addr=10.10.186.33 live As you can see, i have four paths Configuration details about multipath : - in nova.conf [libvirt] volume_use_multipath = True - in cinder.conf [DEFAULT] target_protocol = nvmet_tcp ... [netapp-backend] use_multipath_for_image_xfer = True netapp_storage_protocol = nvme ... /sys/module/nvme_core/parameters/multipath cat /sys/module/nvme_core/parameters/multipath Y nova-compute.log grep -i get_connector_properties /var/log/kolla/nova/nova-compute.log 2025-07-29 14:09:51.553 7 DEBUG os_brick.initiator.connectors.lightos [None req-faf2b0ca-0709-4a70-8302-fa90ad293fd3 4e2ddaf17ee747f2a1f03a392943f80a cb513debb0834ec5b6588356a960bad9 - - default default] LIGHTOS: finally hostnqn: nqn.2014-08.org.nvmexpress:uuid:629788a4-04c6-547c-9121-8d7a39c17fe9 dsc: get_connector_properties /var/lib/kolla/venv/lib/python3.12/site-packages/os_brick/initiator/connectors/lightos.py:115 2025-07-29 14:09:51.553 7 DEBUG os_brick.utils [None req-faf2b0ca-0709-4a70-8302-fa90ad293fd3 4e2ddaf17ee747f2a1f03a392943f80a cb513debb0834ec5b6588356a960bad9 - - default default] <== get_connector_properties: return (30ms) {'platform': 'x86_64', 'os_type': 'linux', 'ip': '10.10.52.161', 'host': 'pkc-dcp-cpt-03', *'multipath': True, 'enforce_multipath': True*, 'initiator': 'iqn.2004-10.com.ubuntu:01:d0bb7aa9bcf1', 'do_local_attach': False, 'nvme_hostid': '5ca8b6d2-aa7d-42d8-bf74-c18484fab68c', 'system uuid': '31343550-3939-5a43-4a44-305930304c48', 'nqn': 'nqn.2014-08.org.nvmexpress:uuid:629788a4-04c6-547c-9121-8d7a39c17fe9', *'nvme_native_multipath': True*, 'found_dsc': '', 'host_ips': ['10.20.128.33', '10.10.184.33', '10.10.186.33', '10.10.52.161', '10.10.22.161', '10.234.2.161', '10.10.50.161', '172.17.0.1', 'fe80::7864:3eff:fe13:5e1f', 'fe80::fc16:3eff:fe7f:3430', 'fe80::4c20:48ff:fe0f:2660']} trace_logging_wrapper /var/lib/kolla/venv/lib/python3.12/site-packages/os_brick/utils.py:204 multipathd systemctl status multipathd.service ○ multipathd.service Loaded: masked (Reason: Unit multipathd.service is masked.) Active: inactive (dead) If you can see some reason to explain why openstack connect to the subsystem only with one path !!! Thanks ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ Rajat Dhasmana 30 juil. 2025 12:37 (il y a 2 jours) À moi, Sean, openstack-discuss On Wed, Jul 30, 2025 at 3:15 PM Vincent Godin <vince.mlist(a)gmail.com> wrote: > Hello guys, > > Some more informations found in the nova-compute.log : > > -try iscsi > > 2025-07-29 14:09:51.523 1222 DEBUG oslo_concurrency.processutils [-] > Running cmd (subprocess): cat /etc/iscsi/initiatorname.iscsi execute > /var/lib/kolla/venv/lib/python3.12/site-packages/oslo_concurrency/processutils.py:349 > 2025-07-29 14:09:51.528 1222 DEBUG oslo_concurrency.processutils [-] CMD > "cat /etc/iscsi/initiatorname.iscsi" returned: 0 in 0.005s execute > /var/lib/kolla/venv/lib/python3.12/site-packages/oslo_concurrency/processutils.py:372 > 2025-07-29 14:09:51.528 1222 DEBUG oslo.privsep.daemon [-] privsep: > reply[90a51cdb-5701-4339-b059-fefb0b79b7a5]: (4, ('## DO NOT EDIT OR REMOVE > THIS FILE!\n## If you remove this file, the iSCSI daemon will not > start.\n## If you change the InitiatorName, existing access control > lists\n## may reject this initiator. The InitiatorName must be unique\n## > for each iSCSI initiator. Do NOT duplicate iSCSI > InitiatorNames.\nInitiatorName=iqn.2004-10.com.ubuntu:01:d0bb7aa9bcf1\n', > '')) _call_back > /var/lib/kolla/venv/lib/python3.12/site-packages/oslo_privsep/daemon.py:503 > > -try lightos ??? > > 2025-07-29 14:09:51.552 7 DEBUG os_brick.initiator.connectors.lightos > [None req-faf2b0ca-0709-4a70-8302-fa90ad293fd3 > 4e2ddaf17ee747f2a1f03a392943f80a cb513debb0834ec5b6588356a960bad9 - - > default default] LIGHTOS: [Errno 111] ECONNREFUSED find_dsc > /var/lib/kolla/venv/lib/python3.12/site-packages/os_brick/initiator/connectors/lightos.py:135 > 2025-07-29 14:09:51.553 7 INFO os_brick.initiator.connectors.lightos [None > req-faf2b0ca-0709-4a70-8302-fa90ad293fd3 4e2ddaf17ee747f2a1f03a392943f80a > cb513debb0834ec5b6588356a960bad9 - - default default] Current host hostNQN > nqn.2014-08.org.nvmexpress:uuid:629788a4-04c6-547c-9121-8d7a39c17fe9 and > IP(s) are ['10.20.128.33', '10.10.184.33', '10.10.186.33', '10.10.52.161', > '10.10.22.161', '10.234.2.161', '10.10.50.161', '172.17.0.1', > 'fe80::7864:3eff:fe13:5e1f', 'fe80::fc16:3eff:fe7f:3430', > 'fe80::4c20:48ff:fe0f:2660'] > 2025-07-29 14:09:51.553 7 DEBUG os_brick.initiator.connectors.lightos > [None req-faf2b0ca-0709-4a70-8302-fa90ad293fd3 > 4e2ddaf17ee747f2a1f03a392943f80a cb513debb0834ec5b6588356a960bad9 - - > default default] LIGHTOS: did not find dsc, continuing anyway. > get_connector_properties > /var/lib/kolla/venv/lib/python3.12/site-packages/os_brick/initiator/connectors/lightos.py:112 > 2025-07-29 14:09:51.553 7 DEBUG os_brick.initiator.connectors.lightos > [None req-faf2b0ca-0709-4a70-8302-fa90ad293fd3 > 4e2ddaf17ee747f2a1f03a392943f80a cb513debb0834ec5b6588356a960bad9 - - > default default] LIGHTOS: finally hostnqn: > nqn.2014-08.org.nvmexpress:uuid:629788a4-04c6-547c-9121-8d7a39c17fe9 dsc: > get_connector_properties > /var/lib/kolla/venv/lib/python3.12/site-packages/os_brick/initiator/connectors/lightos.py:115 > > -then > > 2025-07-29 14:09:51.553 7 DEBUG os_brick.utils [None > req-faf2b0ca-0709-4a70-8302-fa90ad293fd3 4e2ddaf17ee747f2a1f03a392943f80a > cb513debb0834ec5b6588356a960bad9 - - default default] <== > get_connector_properties: return (30ms) {'platform': 'x86_64', 'os_type': > 'linux', 'ip': '10.10.52.161', 'host': 'pkc-dcp-cpt-03', 'multipath': True, > 'enforce_multipath': True, 'initiator': > 'iqn.2004-10.com.ubuntu:01:d0bb7aa9bcf1', 'do_local_attach': False, > 'nvme_hostid': '5ca8b6d2-aa7d-42d8-bf74-c18484fab68c', 'system uuid': > '31343550-3939-5a43-4a44-305930304c48', 'nqn': > 'nqn.2014-08.org.nvmexpress:uuid:629788a4-04c6-547c-9121-8d7a39c17fe9', > 'nvme_native_multipath': True, 'found_dsc': '', 'host_ips': > ['10.20.128.33', '10.10.184.33', '10.10.186.33', '10.10.52.161', > '10.10.22.161', '10.234.2.161', '10.10.50.161', '172.17.0.1', > 'fe80::7864:3eff:fe13:5e1f', 'fe80::fc16:3eff:fe7f:3430', > 'fe80::4c20:48ff:fe0f:2660']} trace_logging_wrapper > /var/lib/kolla/venv/lib/python3.12/site-packages/os_brick/utils.py:204 > 'multipath': True, 'enforce_multipath': True This shows that multipath configuration is set correctly. It would be good to search for this log entry[1] in cinder-volume logs and see the *portals *field to verify how many portals does the netapp nvme driver returns *Initialize connection info:* https://github.com/openstack/cinder/blob/master/cinder/volume/drivers/netap… > 2025-07-29 14:09:51.554 7 DEBUG nova.virt.block_device [None > req-faf2b0ca-0709-4a70-8302-fa90ad293fd3 4e2ddaf17ee747f2a1f03a392943f80a > cb513debb0834ec5b6588356a960bad9 - - default default] [instance: > 3fcb3e36-1890-44f7-9c3c-283c05e91910] Updating existing volume attachment > record: b81aea6e-f2ae-4781-8c2e-3b7f1606ba0d _volume_attach > /var/lib/kolla/venv/lib/python3.12/site-packages/nova/virt/block_device.py:666 > 2025-07-29 14:09:53.680 7 DEBUG os_brick.initiator.connectors.nvmeof [None > req-faf2b0ca-0709-4a70-8302-fa90ad293fd3 4e2ddaf17ee747f2a1f03a392943f80a > cb513debb0834ec5b6588356a960bad9 - - default default] ==> connect_volume: > call "{'self': <os_brick.initiator.connectors.nvmeof.NVMeOFConnector object > at 0x7cf65c576090>, 'connection_properties': {'target_nqn': > 'nqn.1992-08.com.netapp:sn.ec2c63655c3d11f0a40ad039eaba99f2:subsystem.openstack-79f1de4a-6645-4b47-9377-f06db6c2e0b5', > 'host_nqn': > 'nqn.2014-08.org.nvmexpress:uuid:629788a4-04c6-547c-9121-8d7a39c17fe9', > 'portals': [['10.10.184.3', 4420, 'tcp']], 'vol_uuid': > '69da9918-7e84-4ee4-b7bb-9b50e3e6d739', 'qos_specs': None, 'access_mode': > 'rw', 'encrypted': False, 'cacheable': False, 'enforce_multipath': True}}" > trace_logging_wrapper > /var/lib/kolla/venv/lib/python3.12/site-packages/os_brick/utils.py:177 > 'portals': [['10.10.184.3', 4420, 'tcp']] Here we can see that there is only one portal returned by the netapp driver

1 0

[Neutron] - General thoughts on tenancy network MTU
by Karl Kloppenborg 01 Aug '25

01 Aug '25

Hi Neutrinos, I was discussing with a colleague about our MTU settings within our Openstack regions, generally speaking we have a physnet_global_mtu of 1550 with tenancy networks automatically provisioned as 1500 VXLAN. This ends up with VM’s receiving DHCP MTU settings of 1500 which is fine, however reading about yesterday’s discussion on OVN performance, Nguyen’s recommendation was to enable Jumboframes. This got me thinking, what do you set your tenancy and phynet MTU’s to? Very interested to hear about your experiences with running 9k MTU’s on the VM networks etc, what impact this has on OVS/OVN routers and northbound connectivity being 1500. 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>

2 1

(Ceilometer) Openstack - Kolla-Ansible deployment - Ceilometer (Central & compute) Docker Containers are unhealthy
by TRB PREM KUMAR 01 Aug '25

01 Aug '25

Hi, We have deployed an all-in-one OpenStack server for billing. Now ceilometer containers are unhealthy. Please help us to resolve this issue. Reference Output for reference: trb1@openstack-aio-01:~$ docker ps | grep ceil c53fc69ba42b quay.io/openstack.kolla/ceilometer-compute:2024.2-rocky-9 "dumb-init --single-…" About a minute ago Up About a minute *(unhealthy) * ceilometer_compute 9337af646e0f quay.io/openstack.kolla/ceilometer-central:2024.2-rocky-9 "dumb-init --single-…" 30 minutes ago Up About a minute ( *unhealthy)* ceilometer_central 554c4b8ccd86 quay.io/openstack.kolla/ceilometer-notification:2024.2-rocky-9 "dumb-init --single-…" 4 days ago Up About a minute (healthy) ceilometer_notification *** Logs files are attached for reference. Regards, TRB.

3 6

[neutron] Drivers meeting canceled Friday, August 1st
by Brian Haley 31 Jul '25

31 Jul '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