November 2025 - openstack-discuss

[release] Release countdown for week R-20, Nov 10 - 14
by Elõd Illés 07 Nov '25

07 Nov '25

Development Focus ----------------- The Gazpacho-1 milestone is next week, on November 13th, 2025! Project team plans for the 2026.1 Gazpacho cycle should now be solidified. General Information ------------------- Libraries need to be released at least once per milestone period. Next week, the release team will propose releases for any library which had changes but has not been otherwise released since the 2025.2 Flamingo release. PTL's or release liaisons, please watch for these and give a +1 to acknowledge them. If there is some reason to hold off on a release, let us know that as well, by posting a -1. If we do not hear anything at all by the end of the week, we will assume things are OK to proceed. NB: If one of your libraries is still releasing 0.x versions, start thinking about when it will be appropriate to do a 1.0 version. The version number does signal the state, real or perceived, of the library, so we strongly encourage going to a full major version once things are in a good and usable state. Upcoming Deadlines & Dates -------------------------- Gazpacho-1 milestone: November 13th, 2025 Előd Illés irc: elodilles @ #openstack-release

1 0

[Action required] Glanceclient freeze in I cycle
by Cyril Roelandt 07 Nov '25

07 Nov '25

Hello, The Glance team is planning on freezing development on python-glancelient. Starting in the I cycle, the client will go into maintenance mode, and new features will no longer be implemented. Users are encouraged to use the OpenStack client instead and report bugs or missing features to the SDK or OSC projects. The following projects currently use glanceclient as a library: - ceilometer[1] - cinder - cyborg - freezer - heat - heat-translator - horizon - magnum - manila[2] - mistral-extra - nova - octavia - os-client-config - rally-openstack - skyline-apiserver[3] - sunbeam-charms - trove - venus[4] - vitrage-tempest-plugin - zun The Glance team has proposed some migration patches already to some of the affected projects. We would appreciate your team's quick attention to reviewing these patches during this cycle. Additionally, we will be happy to help review migration patches proposed by your team. Use the topic 'remove-glanceclient' so we can easily find them. We're starting the migration process now in Gazpacho so that we can discover and address any feature gaps well in advance of the glanceclient going dark in the I release. On behalf of the Glance team, Cyril Roelandt [1] https://review.opendev.org/c/openstack/ceilometer/+/963632 [2] https://review.opendev.org/c/openstack/manila/+/935835 [3] https://review.opendev.org/c/openstack/skyline-apiserver/+/963862 [4] https://review.opendev.org/c/openstack/venus/+/931291

1 0

[tacker][ptg] 2026.1 Gazpacho PTG summary
by Yasufumi Ogawa 07 Nov '25

07 Nov '25

Hi all, I'd like to share a brief summary of Tacker vPTG. Please refer to our etherpad [1] for whole the duscussion. [1] https://etherpad.opendev.org/p/oct2025-ptg-tacker ## Enhancing Tacker Testing Coverage in the OpenStack Helm Check Pipeline - It's a recap from the previous cycle. To expand the test coverage, improve Tacker testing within the OpenStack Helm (OSH) pipeline by adding more test cases. - Use the OpenStack CLI for Tacker testing, ensuring that no modifications to the OSH test code will be needed even if Tacker's functional tests change. ## Tosca-parser 2.13.0 Validation Failures – Tacker Handling Strategy for Specification Gaps in ETSI SOL001 v2.6.1 - Address the validation failures in tosca-parser happened after it's updated to v2.13.0. - Some VNFDs in tacker's repo are still old and invalid for the stricter validations, but required to be not changed for keeping compatibility with ETSI std version v2.6.1. - We introduced temporary fix just for passing the tests as a remedy, but haven't conclude our policy how we keep the compatibility. As the result, current tacker impl isn't fully compatible with ETSI std. - Continue the discussion for the policy while adding a note for describing the current status of the issue on docs. ## Approach to Prevent Broken Reference URLs in Tacker Documentation - For better maintenance, introduce a periodic job for detecting invalid links. ## Proposal for New Compliance Testcase Implementation for ETSI TST010 Release 3 - Implement new ETSI TST010 Release 3 (v3.3.1) testcases to continue alignment with the ETSI std and strengthen its compliance verification capabilities for VNFM APIs. ## Enabling VNF Support in Prometheus Plugin for Fault Management - Extend Tacker's Prometheus Plugin to enable Fault Management support for VNFs which suppports only CNFs. ## Fix VNF-Package Multi-tenancy issues - Enable multi-tenancy support in VNF Package management by changing the uniqueness scope of vnfd_id from global to per-project. - Due to the current NFV does not support VNF level multi-tenant and it might be a gap between ETSI std, continue to discuss how we fill the gap, for example, making a feedback for multi-tenancy usecase or so. ## Confirm support versions for k8s/Helm/Prometheus on Tacker Gazpacho - The current support versions of k8s/Helm/Prometheus aren't the latest since we've had a failure of updating patch and cannot be fixed yet. - Fix the issue and update to the latest. ## Eventlet removal (Community goal) - Tacker depends on eventlet and need to be modified for the removal. - NEC will discuss if we can proceed with this work. ## Bug triage - Revise Bug maintenance on launchpad for closing too old bugs labeled as critical but can be discarded anymore or so. - Go through the bug list and give comments about their related bugs Thanks, Yasufumi

1 0

[qa] Tempest gate blocked and dropping python 3.9
by Ghanshyam Maan 07 Nov '25

07 Nov '25

Hi All, Requirement repo has dropped the Python 3.9 constraints[1], and due to that, the Tempest gate is blocked because the Python 3.9 unit test job is failing. We discussed this type of issue in the past[2], that if the requirement repo drops older Python version constraints, then Tempest can drop the support of that Pythion version. Tempest master can still be used to test the Python 3.9 env; for that, you need to install tempest in a Python 3.10 (or higher) env. I have proposed the change to drop py3.9[3], and Yatin's change will unblock the stable branch testing[4]. Hold your recheck until those fixes are merged. [1] https://review.opendev.org/c/openstack/requirements/+/957587 [2] https://lists.openstack.org/pipermail/openstack-discuss/2022-May/028711.html [3] https://review.opendev.org/c/openstack/tempest/+/966101 [4] https://review.opendev.org/c/openstack/tempest/+/965903 -gmaan

1 3

[watcher] Unmaintained branch cleanup
by Joan Gilabert 06 Nov '25

06 Nov '25

Hi everyone, Watcher currently has two unmaintained branches[1], unmaintained/2024.1 and unmaintained/2023.1. The latter has not had any patch in 2 years [2] so we plan to move it to eol. We will discuss it in the next Watcher IRC meeting, but I'm writing this message early to give everyone a chance to raise any objection. Please respond to this message if you have any objection, if there are none, I will propose a patch to move the branch next Thursday, after the Watcher IRC meeting and share the link here. Regards, Joan [1] https://opendev.org/openstack/watcher/branches [2] https://opendev.org/openstack/watcher/commits/branch/unmaintained/2023.1

2 2

[kolla-ansible] nova ceph backend
by Jonathan Proulx 06 Nov '25

06 Nov '25

Hi All, looking at https://docs.openstack.org/kolla-ansible/2025.1/reference/storage/external-… To use ceph with my particular setup it seems I need to set this in globals.yml: nova_backend_ceph: "yes" ceph_nova_user: "nova" ceph_nova_pool_name: "ov-vms" And provide the keyring file in config/nova/ceph.client.nova.keyring I'm not configuring cells explicitly but when I run `kolla-ansible reconfigure --tags nova` I get: ASK [nova-cell : Check cinder keyring file] ************************************************************************** fatal: [kvmgen6-0.csail.mit.edu -> localhost]: FAILED! => {"msg": "The task includes an option with an undefined variable.. ['{{ node_custom_config }}/nova/{{ inventory_hostname }}/{{ keyring }}', '{{ node_custom_config }}/nova/{{ keyring }}']: {{ nova_cell_ceph_backend['cluster'] }}.client.{{ nova_cell_ceph_backend['volumes']['user'] }}.keyring: 'dict object' has no attribute 'volumes'\n\nThe error appears to be in '/opt/kolla/venv/share/kolla-ansible/ansible/roles/nova-cell/tasks/external_ceph.yml': line 17, column 3, but may\nbe elsewhere in the file depending on the exact syntax problem.\n\nThe offending line appears to be:\n\n\n- name: Check cinder keyring file\n ^ here\n"} Digging through the code in roles/nova-cell/tasks/external_ceph.yml I kind of make it go by adding: nova_cell_ceph_backend: cluster: "ceph" vms: user: "{{ ceph_nova_user }}" pool: "{{ ceph_nova_pool_name }}" volumes: user: "{{ ceph_nova_user }}" pool: "{{ ceph_nova_pool_name }}" but I can find no reference in the docs to this and don't understand what in needs "volumes" for (And suspect it should be using some cinder stuff for that?) What have I done here? The nova backend "works" but I worry about how I got here since nova+cinder is very common and I shoudl not have needed to leave the documented path so I worry there's a deeper error in my config that caused this. Thanks, -Jon -- Jonathan Proulx (he/him) Sr. Technical Architect The Infrastructure Group MIT CSAIL

2 2

[nova] NVLink passthrough
by Pavlo Shchelokovskyy 05 Nov '25

05 Nov '25

Hi all, This is a continuing thread from 3 years ago here: https://lists.openstack.org/pipermail/openstack-discuss/2022-June/029273.ht… We've recently faced the same issue re Nvidia NVLink / NVSwitch, and I wanted to share how we are solving it. Given: - server with 8x Nvidia H200 pGPUs aimed to be used as PCI passthrough - separate pGPUs can be connected with NVLink but not any with any - there are 4 specific combinations to use when pairing 2 gpus - gpu1+gpu3, gpu2+gpu4, gpu5+gpu7, gpu6+gpu8 - and there are only 2 possible combinations of pairing 4 gpus - gpu{1..4} and gpu{5..8} The requirement is to have a single flavor that would ask for 2 GPUs, and the scheduling would pick only appropriate pair where NVLink between GPUs is possible, and compute will enable/disable NVLink for those GPUs as appropriate (same for 4 GPUs flavor). The compute part is solved by a libvirt hook provided by Nvidia here https://github.com/NVIDIA/libvirt-hooks/. Given the correct devices are chosen by Nova to be passed into the VM, the hook will enable NVLink between them. However, that scheduling part is currently rather impossible with Nova as-is. The best one can do is assign separate trait to appropriate pairs and quartets of GPUs, and then have 4 flavors for 2-GPU configuration and 2 flavors for the 4-GPU one. This if course is very inefficient and brittle, and can not work in a self-service cloud. What we are trying to do is the following: - add a new flavor extra spec `placement:same_subtree`. The value will be passed directly to placement's allocation candidates API. - in order for this to be usable in a flavor, we need predictable resource group names generated for PCI devices. Right now they are auto-generated from request-id, which won't work. - hence we extended `pci_passthrough:alias` spec to have an optional `:group_prefix` part. Then, what we do is reshape the PCI resource provider tree a bit. We introduce two extra layers of providers, let's call them `group4` and `group2`, each group has a specific trait, for example `CUSTOM_PCI_GROUP_OF_2` and `CUSTOM_PCI_GROUP_OF_4`. Two `group4` providers have compute nodes as a parent, and are parent to two `group2` providers each. Then we re-parent PCI resource providers to `group2` providers, so that each `group2` and `group4` tree corresponds to a set of GPUs that can be connected via NVLink. Luckily enough, resource tracker of nova-compute does not care about the parent provider, as long as the name and ID of PCI resource providers are not changed, so the reshape has no effect on the resource tracker. We also need to use all this with Aggregate Extra Spec filter active, so we've duplicated the `group_policy` flavor extra spec to `placement:group_policy` one. And of course, for all of this to work, one has to enable "PCI in placement" feature too https://docs.openstack.org/nova/2025.2/admin/pci-passthrough.html#pci-track… As a result, assuming the PCI alias for the GPUs is `h200` and its resource class is `PGPU`, we can create the following flavor extra spec: pci_passthrough:alias=h200:2:_nvlink2 trait_groupof2:CUSTOM_PCI_GROUP_OF_2=required placement:group_policy=none placement:same_subtree=_nvlink2-0,_nvlink2-1,_groupof2 that will result in the following placement query: GET /allocation_candidates ?resources_nvlink2-0=PGPU:1 &resources_nvlink2-1=PGPU:1 &required_groupof2=CUSTOM_PCI_GROUP_OF_2 &group_policy=none &same_subtree=_nvlink2-0,_nvlink2-1,_groupof2 That will select only a pair of GPUs that are children of a single provider with `CUSTOM_PCI_GROUP_OF_2` trait - which is exactly what we need! You can find this work proposed as a patch at https://review.opendev.org/966205. This is definitely just a beginning of discussion, and most certainly would require a spec, so I am eager to hear your thoughts and comments :-) Cheers, pas-ha -- Dr. Pavlo Shchelokovskyy Principal Software Engineer Mirantis Inc www.mirantis.com

2 1

[horizon][PTG] 2026.1 Gazpacho PTG summary
by Tatiana Ovchinnikova 05 Nov '25

05 Nov '25

Hello everyone, A huge thank you to everyone who joined the OpenStack Horizon team for the Gazpacho PTG, who organized sessions, presented topics, and actively contributed to the discussions! Thank you for making the PTG a success! The full list of sessions and topics can be found on our Etherpad [1] Here is the summary of the topics: # Flamingo Retrospective A review of the previous Flamingo cycle, highlighting positive developments like switching to SDK for certain services, improving TOTP setup, and improving region/domain selection. # Gazpacho Cycle Planning Planning for the current Gazpacho cycle, establishing AngularJS removal as the top priority. Other key goals include investigating the removal of old integration tests and planning for Django 5.2 support. # Open Discussion A session for discussing various in-progress code reviews. Topics included a discussion on a feature to add changing instance password support. # Django 5.2 Support Discussion on the plan to adopt Django 5.2, the latest LTS release. # Tests Review of current test stability and plans for test code cleanup. The team noted that both horizon-integration-pytest and horizon-ui-pytest are currently stable and plans to remove old integration tests from the repository are moving forward. We also discussed progress on implementing Manila UI integration tests as a template for other plugin teams. # Towards New OpenStack contributors: An OpenInfra User Group Kenya Story A presentation by Agnes Nduta to share the experiences and strategies of the OpenInfra User Group Kenya in successfully onboarding new contributors into the OpenStack ecosystem. # Contributor/Maintainer Surveys and Metrics Analysis A review of current project health using metrics and analysis from contributor and maintainer surveys. # How to create a Cursor MCP for analyzing Horizon code A walk-through demonstrating the steps required to set up a Cursor Maintainer Candidate Program (MCP) for analyzing Horizon code. # Multi-Realm Support and Multi-Region Support discussion A dedicated cross project session to discuss the implementation and implications of providing Multi-Realm and Multi-Region support within the Horizon dashboard. More details can be found on the separate Etherpad [2]. [1] https://etherpad.opendev.org/p/horizon-gazpacho-ptg [2] https://etherpad.opendev.org/p/multi-realm With kind regards, Tatiana

1 0

Nova error for fetch or server create after upgrade
by Ahmad Milad Pour 05 Nov '25

05 Nov '25

Hello there, I did upgrade the packages and repo, and something were upgraded: BEFORE: root@gregion83:~# apt-cache policy nova-api | head -n 10 nova-api: Installed: 3:29.2.0-0ubuntu1.1 AFTER: root@gregion83:~# apt-cache policy nova-api | head nova-api: Installed: 3:31.0.0-0ubuntu1.2~cloud0 I also did add "DEBUG=True" under "default" section of /etc/nova/nova.conf in my region and tried to create server, but I cannot find any important logs or details to see what's wrong: ==> /var/log/nova/nova-api.log <== 2025-11-05 14:42:44.524 2960 INFO nova.osapi_compute.wsgi.server [-] 185.137.25.83 "GET /v2.1 HTTP/1.1" status: 200 len: 790 time: 0.0164449 2025-11-05 14:42:45.615 2960 ERROR nova.api.openstack.wsgi [None req-892920aa-c4be-4aea-abab-aa8e9fe8c7e0 64c74c80ec9a4a31ae27b82af846b36a 906db1c682bc4e3db 822c2e6dbc9cb6a - - default default] Unexpected exception in API method: neutronclient.common.exceptions.InternalServerError: Request Failed: internal serve r error while processing your request. Neutron server returns request_ids: ['req-80f3ccda-11ee-4417-a27c-2437540e6ee0'] 2025-11-05 14:42:45.615 2960 ERROR nova.api.openstack.wsgi exception_handler_v20(status_code, error_body) 2025-11-05 14:42:45.615 2960 ERROR nova.api.openstack.wsgi File "/usr/lib/python3/dist-packages/neutronclient/v2_0/client.py", line 90, in exception_handler_v20 2025-11-05 14:42:45.615 2960 ERROR nova.api.openstack.wsgi raise client_exc(message=error_message, 2025-11-05 14:42:45.615 2960 ERROR nova.api.openstack.wsgi neutronclient.common.exceptions.InternalServerError: Request Failed: internal server error while processing your request. 2025-11-05 14:42:45.615 2960 ERROR nova.api.openstack.wsgi Neutron server returns request_ids: ['req-80f3ccda-11ee-4417-a27c-2437540e6ee0'] 2025-11-05 14:42:45.615 2960 ERROR nova.api.openstack.wsgi 2025-11-05 14:42:45.628 2960 INFO nova.api.openstack.wsgi [None req-892920aa-c4be-4aea-abab-aa8e9fe8c7e0 64c74c80ec9a4a31ae27b82af846b36a 906db1c682bc4e3db822c2e6dbc9cb6a - - default default] HTTP exception thrown: Unexpected API Error. Please report this at http://bugs.launchpad.net/nova/ and attach the Nova API log if possible. <class 'neutronclient.common.exceptions.InternalServerError'> 2025-11-05 14:42:45.632 2960 INFO nova.osapi_compute.wsgi.server [None req-892920aa-c4be-4aea-abab-aa8e9fe8c7e0 64c74c80ec9a4a31ae27b82af846b36a 906db1c682bc4e3db822c2e6dbc9cb6a - - default default] 185.137.25.83 "GET /v2.1/servers/c18f669d-1338-42dd-947f-c40217238450 HTTP/1.1" status: 500 len: 660 time: 1.1018338 My last openstack version was 6.6.0, and I did upgrade after another email I sent "How to install Flamingo openstack in Ubuntu 24". Before upgrade, everything was working fine, but now I have issue. Would you please help me for this? Regards, Ahmad

2 3

How to install Flamingo openstack in Ubuntu 24
by Ahmad Milad Pour 05 Nov '25

05 Nov '25

Hello there, I use Ubuntu 24 and I did try to install openstack, but it seems it's not the latest one. root@gregion83:~# cat /etc/os-release PRETTY_NAME="Ubuntu 24.04.3 LTS" NAME="Ubuntu" VERSION_ID="24.04" VERSION="24.04.3 LTS (Noble Numbat)" VERSION_CODENAME=noble ID=ubuntu ID_LIKE=debian HOME_URL="https://www.ubuntu.com/" SUPPORT_URL="https://help.ubuntu.com/" BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/" PRIVACY_POLICY_URL=" https://www.ubuntu.com/legal/terms-and-policies/privacy-policy" UBUNTU_CODENAME=noble LOGO=ubuntu-logo root@gregion83:~# openstack --version openstack 6.6.0 root@gregion83:~# apt-cache policy nova-api | head -n 10 nova-api: Installed: 3:29.2.0-0ubuntu1.1 Candidate: 3:29.2.0-0ubuntu1.2 Version table: 3:29.2.0-0ubuntu1.2 500 500 http://archive.ubuntu.com/ubuntu noble-updates/main amd64 Packages *** 3:29.2.0-0ubuntu1.1 100 100 /var/lib/dpkg/status 3:29.0.1-0ubuntu1.4 500 500 http://security.ubuntu.com/ubuntu noble-security/main amd64 Packages root@gregion83:~# apt-cache policy openstack-dashboard | head -n 10 openstack-dashboard: Installed: 4:24.0.1-0ubuntu0.24.04.1 Candidate: 4:24.0.1-0ubuntu0.24.04.1 Version table: *** 4:24.0.1-0ubuntu0.24.04.1 500 500 http://archive.ubuntu.com/ubuntu noble-updates/main amd64 Packages 100 /var/lib/dpkg/status 4:24.0.0-0ubuntu1 500 500 http://archive.ubuntu.com/ubuntu noble/main amd64 Packages root@gregion83:~# curl -s -H "X-Auth-Token: $(openstack token issue -c id -f value)" http://$HOSTNAME:8774 | jq { "versions": [ { "id": "v2.0", "status": "SUPPORTED", "version": "", "min_version": "", "updated": "2011-01-21T11:33:21Z", "links": [ { "rel": "self", "href": "http://gregion83.domain.com:8774/v2/" } ] }, { "id": "v2.1", "status": "CURRENT", "version": "2.96", "min_version": "2.1", "updated": "2013-07-23T11:33:21Z", "links": [ { "rel": "self", "href": "http://gregion83.com:8774/v2.1/" } ] } ] } That's the information I thought is good for the help. And that's the error I have: root@gregion83:~# openstack server rebuild --image 608349cf-8743-4339-8e2c-e707f89be64f --no-user-data c18f669d-1338-42dd-947f-c40217238450 --os-compute-api-version 2.54 or greater is required to support the --no-user-data option root@gregion83:~# openstack server rebuild --image 608349cf-8743-4339-8e2c-e707f89be64f --user-data /dev/null c18f669d-1338-42dd-947f-c40217238450 --os-compute-api-version 2.54 or greater is required to support the --user-data option I see this link from which I can install: https://docs.openstack.org/horizon/2025.2/install/install-ubuntu.html How to resolve this issue? Regards, Ahmad

3 4