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

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