- openstack-discuss - lists.openstack.org

[neutron] Bug deputy Jan 5 - Jan 11
by Rodolfo Alonso Hernandez 12 Jan '26

12 Jan '26

Hello Neutrinos: This is the list of bugs created during the last week: * Critical ** networking-bgpvpn and neutron-vpnaas unit tests arefailing due to tenant_id to project_id migration ( https://bugs.launchpad.net/neutron/+bug/2137489) Fixes merged and bug closed. * High: ** devstack deployment failing on stable/2025.1 branch without wsgi ( https://bugs.launchpad.net/neutron/+bug/2137540) Fix proposed: https://review.opendev.org/c/openstack/neutron/+/972669 (tested in https://review.opendev.org/c/openstack/neutron-tempest-plugin/+/972266) * Medium ** neutron.tests.functional.services.bgp.test_ovn.TestBgpOvnLocking.test_locking_mechanism randomly fails with AssertionError: Second API did not lose the lock ( https://bugs.launchpad.net/neutron/+bug/2137467) In progress: https://review.opendev.org/c/openstack/neutron/+/972547 ** ``get_api_worker_id`` should not fail if ``uwsgi`` module is not installed (https://bugs.launchpad.net/neutron/+bug/2137715) Fix proposed: https://review.opendev.org/c/openstack/neutron/+/972687 (needed up to 2025.2) Regards.

1 0

Upcoming metrics dashboard changes
by Ildiko Vancsa 11 Jan '26

11 Jan '26

Hi OpenStack community, Since the OpenInfra Foundation joined the Linux Foundation, we have been looking into opportunities to take advantage of the frameworks and tool sets that the Linux Foundation has, and some of you and your organizations are already familiar with. While the dashboards are still being built I would like to let you know that, as part of that effort, we will switch to LFX Insights[1] as the metrics dashboard for OpenInfra projects, including OpenStack, starting on __January 15, 2026.__ A couple things to note: - The new OpenStack metrics dashboard[2] is already available, but it is __still under active construction.__ - The set of metrics that is displayed on the new dashboard will not be identical with the metrics on the dashboard provided by Bitergia. - LFX Insights does not display affiliation information for individuals who are listed on the dashboard as contributors, for privacy reasons. However, if you already have an LF account[3], you will be able to check and update your affiliation information. Or, you can create a new LF account[4]. - You can learn more about the dashboard in the LFX Insights documentation[5]. - If your organization is an OpenInfra Foundation / Linux Foundation member already, the LF Organization Dashboard[6] is also available for a more company-centric view. The OpenStack Bitergia metrics dashboard[7] remains available __until January 14, 2026.__ Please let me know if you have any questions. Best Regards, Ildikö [1] https://insights.linuxfoundation.org/ [2] https://insights.linuxfoundation.org/project/OpenStack/ [3] https://openprofile.dev/ [4] https://docs.linuxfoundation.org/lfx/sso/create-an-account [5] https://insights.linuxfoundation.org/docs/introduction/what-is-insights/ [6] https://lfx.linuxfoundation.org/tools/organization-dashboard/ [7] https://openstack.biterg.io/ ——— Ildikó Váncsa Director of Community OpenInfra Foundation

3 2

[tacker] Cancelling weekly IRC meeting
by Yasufumi Ogawa 11 Jan '26

11 Jan '26

Hi tacker team, Due to a holiday in Japan and most of team members aren't join, I'm cancelling meeting this week. Regards, Yasufumi

1 0

[release] Release countdown for week R-11, Jan 12 - 16
by Elõd Illés 09 Jan '26

09 Jan '26

Development Focus ----------------- We are now past the Gazpacho-2 milestone, and entering the last development phase of the cycle. Please review the late milestone-2 release patches at https://review.opendev.org/q/topic:gazpacho-milestone-2 if you have not done so already! Teams should otherwise be focused on implementing planned work for the cycle. Now is a good time to review those plans and reprioritize anything if needed based on the what progress has been made and what looks realistic to complete in the next few weeks. General Information ------------------- Looking ahead to the end of the release cycle, please be aware of the feature freeze dates. Those vary depending on deliverable type: * General libraries (except client libraries) need to have their last feature release before Non-client library freeze (February 19th, 2026). Their stable branches are cut early. * Client libraries (think python-*client libraries) need to have their last feature release before Client library freeze (February 26th, 2026) * Deliverables following a cycle-with-rc model (that would be most services) observe a Feature freeze on that same date, February 26th, 2026. 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 (March 12th, 2026) * Deliverables following cycle-with-intermediary model can release as necessary, but in all cases before Final RC deadline (March 26th, 2026) Upcoming Deadlines & Dates -------------------------- Non-client library freeze: February 19th, 2026 (R-6 week) Client library freeze: February 26th, 2026 (R-5 week) Gazpacho-3 milestone: February 26th, 2026 (R-5 week) Előd Illés irc: elodilles @ #openstack-release

1 0

[nova] does resize work with swap & no-swap flavor combo for image-backed server having vol attached
by tomergaurav1031＠gmail.com 09 Jan '26

09 Jan '26

Hi Team, I’ve encountered resize causing issues if source flavor has swap-disabled and target flavor have it enabled or vice-versa. It results into duplicate vdb error. Following are the steps:- 1 Create an image-backed(no volume attached) instance with flavor having swap disabled. 2 Create a volume and attach it with the instance (e.g. get attached at /dev/vdb). 3 Resize it to a bigger flavor which has swap & ephemeral enabled. 4 It results into error complaining about duplicate vdb:- libvirt.libvirtError: XML error: target 'vdb' duplicated for disk sources '/var/lib/nova/instances/1860acb4-012f-4528-b2ef-XXXXX/disk.swap' Should one not do resize with swap & no-swap flavor combo? Please provide thoughts/suggestions for the same. Thanks, Gaurav

2 1

[ceilometer] ceilometer metrics for list fields in event payloads
by NITIN GUPTA 09 Jan '26

09 Jan '26

Hello Ceilometer Team! Good Day! Could you please suggest, how to create ceilometer metrics for list fields in event payloads when creating Gnocchi resources? Looks like Ceilometer doesn't iterate over list fields in event payloads when creating Gnocchi resources. Is this a known issue? From the below Sample payload, I'm looking to create a separate metric for "vcpus" field (for example) from each item in "reservations", which is a list of dictionary type of data in the payload. 'payload': { 'lease_id': 'f94182be-70e2-4f3f-bc8d-a1d1c2eea0aa', 'user_id': '2cf63f4ecf7740f5ac9ef4adfa4cdf5e', 'project_id': '07f1a09ab11543bb9080d260a98d812c', 'trust_id': '0037eb9121f04cdc94c39628a8354dde', 'start_date': '2025-12-15T16:18:00.000000', 'end_date': '2025-12-15T16:22:00.000000', 'status': 'PENDING', '*reservations*': [ { 'id': '1fffeb17-599d-441a-80e0-ca6d9044fd36', 'lease_id': 'f94182be-70e2-4f3f-bc8d-a1d1c2eea0aa', 'resource_id': 'c9daade3-4a85-4122-bec2-f34b7a849a01', 'resource_type': 'virtual:instance', 'status': 'pending', 'missing_resources': False, 'resources_changed': False, 'created_at': '2025-12-15 16:18:07', 'updated_at': '2025-12-15 16:18:10', '*vcpus*': 1, 'memory_mb': 1024, 'disk_gb': 20, 'amount': 1, 'affinity': None, 'resource_properties': '', 'flavor_id': '1fffeb17-599d-441a-80e0-ca6d9044fd36', 'aggregate_id': 292, 'server_group_id': None }, { 'id': '97df8162-d756-44c0-a27f-c832101577e8', 'lease_id': 'f94182be-70e2-4f3f-bc8d-a1d1c2eea0aa', 'resource_id': '4a3e20b1-5f63-46b1-a61b-13a267fd829a', 'resource_type': 'virtual:instance', 'status': 'pending', 'missing_resources': False, 'resources_changed': False, 'created_at': '2025-12-15 16:18:05', 'updated_at': '2025-12-15 16:18:07', '*vcpus*': 1, 'memory_mb': 1024, 'disk_gb': 20, 'amount': 1, 'affinity': None, 'resource_properties': '', 'flavor_id': '97df8162-d756-44c0-a27f-c832101577e8', 'aggregate_id': 291, 'server_group_id': None } ], 'events': [{'id': '4cea5a4f-53f4-4a69-969b-74a5869c7ab1', 'lease_id': 'f94182be-70e2-4f3f-bc8d-a1d1c2eea0aa', 'event_type': 'end_lease', 'time': '2025-12-15T16:22:00.000000', 'status': 'UNDONE', 'created_at': '2025-12-15 16:18:10', 'updated_at': None}, {'id': '63b51fc9-5eca-4729-8f5e-a3659e7db24b', 'lease_id': 'f94182be-70e2-4f3f-bc8d-a1d1c2eea0aa', 'event_type': 'start_lease', 'time': '2025-12-15T16:18:00.000000', 'status': 'UNDONE', 'created_at': '2025-12-15 16:18:10', 'updated_at': None}, {'id': 'bba382f6-47d8-4bb0-b3aa-0a65c6959ed9', 'lease_id': 'f94182be-70e2-4f3f-bc8d-a1d1c2eea0aa', 'event_type': 'before_end_lease', 'time': '2025-12-15T16:18:00.000000', 'status': 'UNDONE', 'created_at': '2025-12-15 16:18:10', 'updated_at': None}], 'name': 'lease-short-ins', 'created_at': '2025-12-15 16:18:05', 'updated_at': '2025-12-15 16:18:10', 'degraded': False } Best regards. -- NITIN GUPTA

3 11

[Nova] Proposal: NetApp FlexGroup Backend for Ceph-like Ephemeral Storage Performance on NFS
by Borra, Jayaanand 08 Jan '26

08 Jan '26

Hi everyone, Happy New Year to all! I hope you all had a great holiday season. I'm reaching out to share a proposal we've been working on that addresses a performance challenge many enterprises face with ephemeral storage in Nova. Context: Currently, OpenStack deployments running on NFS-based storage (like NetApp FlexGroups) face a significant performance penalty compared to Ceph RBD due to the QCOW2-over-NFS approach. The hypervisor manages Copy-on-Write operations, which introduces: * Double filesystem metadata overhead (QCOW2 on top of NFS) * CPU tax on compute nodes for CoW management * Slower instance provisioning compared to Ceph's instant cloning We are planning to implement solution that leverages NetApp's FlexClone technology through the ONTAP REST API to achieve Ceph-like performance while maintaining the operational simplicity of NFS. Essentially, we're offloading the cloning operation to the storage array itself, making instance creation a metadata-only operation (sub-second) with zero data copying. The implementation involves creating a new NetAppNfs image backend class in nova/virt/libvirt/imagebackend.py that calls the ONTAP REST API's /storage/file/clone endpoint instead of traditional file copy operations. I'm wondering if anyone has insights into: * Similar efforts: Has anyone explored or implemented storage-side cloning for other NFS vendors? * Design concerns: Any architectural red flags with this approach in the Nova driver? * Security practices: Best approach for managing storage credentials and oslo.privsep<vscode-file://vscode-app/Applications/Visual%20Studio%20Code.app/Contents/Resources/app/out/vs/code/electron-browser/workbench/workbench.html> integration? * Community interest: Would this be valuable for other NFS deployments? This will enable high-performance ephemeral storage from, so I'm curious if others have encountered this limitation and whether there's are any known limitation with this approach. Thanks in advance for any guidance or suggestions! Best regards, Jayaanand.

1 0

SECURITY BUG
by Umbrella Corporation 08 Jan '26

08 Jan '26

i found a vulnerability in your git repo so if i reported bugs and vulnerabilities can i get a reward bounty ?

3 3

OpenStack 2026.2 'H' Release Name Poll
by Allison Price 08 Jan '26

08 Jan '26

Hi everyone, Happy New Year! To kick off 2026, I wanted to share the poll to vote for the OpenStack 2026.2 release name, starting with the letter H. The poll will close this Thursday, January 8 at 1700 UTC. https://civs1.civs.us/cgi-bin/vote.pl?id=E_e4708c67d8d7e171&akey=e3b1514078… If you have any questions / comments, please let me know. Cheers, Allison

1 1

[designate] Question about NS record update restriction in multi-region PRIMARY/SECONDARY setup
by Sylvain 08 Jan '26

08 Jan '26

Hi everyone, I hope this email finds you well. I'm reaching out to the community because I'm encountering a limitation with Designate that I don't fully understand, and I'm hoping someone can shed some light on the reasoning behind it or suggest alternative approaches. My Setup I'm running a multi-region Designate deployment with: - 3 independent Designate instances (one per region) - Each instance has its own pool with a single nameserver: - Region 1: ns.region1.net. - Region 2: ns.region2.net. - Region 3: ns.region3.net. This default configuration works perfectly for most of our use cases where zones are region-specific. What I'm Trying to Achieve For certain domains, I need to set up a PRIMARY/SECONDARY configuration across all three regions: - Region 1: PRIMARY zone for example.com - Region 2: SECONDARY zone for example.com - Region 3: SECONDARY zone for example.com For this to work correctly, the PRIMARY zone needs to have NS records pointing to all three nameservers so that: 1. DNS clients can query any of the three nameservers 2. Zone transfers are properly configured between primary and secondaries The Problem When I try to update the NS recordset on the primary zone, I get the error: Updating a root zone NS record is not allowed Steps I'm following: # List recordsets to get the NS recordset ID openstack recordset list example.com. # Attempt to update the NS recordset openstack recordset set example.com. <ns-recordset-id> \ --record ns.region1.net. \ --record ns.region2.net. \ --record ns.region3.net. This happens even when authenticated as an admin user. Why the Default Workaround Doesn't Work I understand that one typical solution is to modify the pool configuration to include all three nameservers. However, this doesn't work in my case because: - I don't want to change the default pool settings since most zones should only use their local regional nameserver - Modifying the pool in Region 1 would affect *all zones* created there, not just the ones I want to replicate My Questions I'm trying to understand the design decisions here, and I'd really appreciate any insights: 1. What's the reasoning behind blocking NS record updates on root zones? I'm not seeing the security or technical concern that this protects against. 2. Is this restriction something that could potentially be made configurable via policy? For example, allowing zone owners to update their own NS records when they have legitimate multi-region or high-availability requirements. 3. Are there any alternative approaches I should be considering for this multi-region PRIMARY/SECONDARY setup that I might be missing? 4. Would the community be open to discussing a potential enhancement that makes this more flexible? I understand if there are concerns, but I'd love to understand them better. Use Case Context This is a fairly standard DNS architecture for high availability and geographic distribution. Many organizations need to run primary and secondary nameservers across different regions or datacenters, and being able to configure the NS records accordingly seems like it should be a supported use case. Thank you very much for taking the time to read this, and I appreciate any guidance or feedback the community can provide! Best regards, Sylvain.

2 2