July 2026 - openstack-discuss - lists.openstack.org

[openstack][neutron][OVN DVR] floating IP issue
by holywine＠outlook.com 13 Jul '26

13 Jul '26

Hello, I deloyed a trial openstack cluster with 3 controllers and 3 computers. Neutron is configured as OVN DVR. As of the network topology a virtual router is created behind the physical router. The network is assigned as blew from VM instance toward Internet: 192.168.0.0/24 - 192.168.1.0/24 - 10.2.46.0/24 The virtual router and the physical router are performing 1-to-1 NAT in between respectively. The system is working well until the servers are power cycled. There seem to be something wrong with floating IP(dnat_and_snat), and VM can't reach Internet anymore. Capturing packet from the WAN port of physical router it turns out that the src IP of the ping request from VM is 192.168.1.182 rather than 192.168.1.71-75 as expected. I can't see any issue from traces below. Can anybody please help? root@infra1:~# ovn-nbctl lr-nat-list neutron-e5f7f842-3188-49bf-9c7c-3f5fac41ecfa TYPE GATEWAY_PORT MATCH EXTERNAL_IP EXTERNAL_PORT LOGICAL_IP EXTERNAL_MAC LOGICAL_PORT dnat_and_snat lrp-5dc8c94e-90a5- 192.168.1.71 192.168.0.160 fa:16:3e:bd:1c:80 a2ce465d-ff66-4d61-a513-d3a6cdc61ad2 dnat_and_snat lrp-5dc8c94e-90a5- 192.168.1.72 192.168.0.103 fa:16:3e:e5:4c:81 708ebc99-3f5f-42b6-8e73-25d15228ba47 dnat_and_snat lrp-5dc8c94e-90a5- 192.168.1.73 192.168.0.120 fa:16:3e:31:bf:76 40c00b27-50cc-43c4-89ba-0c037acfa675 dnat_and_snat lrp-5dc8c94e-90a5- 192.168.1.74 192.168.0.164 fa:16:3e:59:5a:2a 5304617a-f041-4031-b2b9-08feb0e01e85 dnat_and_snat lrp-5dc8c94e-90a5- 192.168.1.75 192.168.0.156 fa:16:3e:f5:0c:86 ed4fb084-ccc5-41ac-8da8-47f3ba6c8485 snat 192.168.1.182 192.168.0.0/24 root@infra1:~# ovn-nbctl find NAT type=dnat_and_snat _uuid : 0b0c5930-efeb-4794-b604-5abd5a2dbcc6 allowed_ext_ips : [] exempted_ext_ips : [] external_ids : {"neutron:fip_external_mac"="fa:16:3e:e5:4c:81", "neutron:fip_id"="7f35acd7-b2e9-40f4-bd65-56223448db71", "neutron:fip_network_id"="90eb7d3b-291b-4080-a57d-b01a6259b583", "neutron:fip_port_id"="708ebc99-3f5f-42b6-8e73-25d15228ba47", "neutron:revision_number"="9", "neutron:router_name"=neutron-e5f7f842-3188-49bf-9c7c-3f5fac41ecfa} external_ip : "192.168.1.72" external_mac : "fa:16:3e:e5:4c:81" external_port_range : "" gateway_port : ad8a50c2-2dff-4ef2-8b06-1f3cc8c01e1e logical_ip : "192.168.0.103" logical_port : "708ebc99-3f5f-42b6-8e73-25d15228ba47" match : "" options : {stateless="false"} priority : 0 type : dnat_and_snat Frank

1 0

[all][oslo][ops][tc] Future of PostgreSQL support
by Takashi Kajinami 12 Jul '26

12 Jul '26

Hello, PostgreSQL support in OpenStack was introduced to oslo.db long time ago and has been there for multiple OpenStack services. However maintaining this backend support has caused multiple challenges (due to limited test coverage and also differences between DBMS which ware not totally hidden by ORM), and neutron eventually decided to remove its PostgreSQL support during 2025.1 cycle[1]. I'm sending this email to gather inputs about current status and needs to maintain the PostgreSQL support, so that we can discuss whether we can globally remove the feature. As I mentioned earlier, Neutron no longer supports PostgreSQL. This means we can no longer use PostgreSQL as a single database backend in OpenStack deployments. Does anyone still want to continue using PostgreSQL for only specific services ? Note that sqlalchemy 2.1 switched the default dialect for PostgreSQL from psycopg2 to psycopg3[2]. This was earlier caught in oslo.db[3] in its test coverage with the latest sqlalchemy. This switch hasn't yet appeared globally because of sqlalchemy still pinned to <2.1 in upper constraints. The switch likely requires adoption efforts (replace psycopg2 libraries in test requirements or update multiple tests to explicitly request psycopg2). Thank you, Takashi [1] https://review.opendev.org/c/openstack/neutron/+/934171 [2] https://docs.sqlalchemy.org/en/21/changelog/changelog_21.html#change-bb4fc9… [3] https://review.opendev.org/c/openstack/oslo.db/+/977543 -- Takashi Kajinami irc: tkajinam github: https://github.com/kajinamit launchpad: https://launchpad.net/~kajinamit

2 1

[tc][all] OpenStack Technical Committee Weekly Summary and Meeting Agenda (2026.2/R-11)
by Goutham Pacha Ravi 12 Jul '26

12 Jul '26

Hello Stackers, We're eleven weeks away from the date of the coordinated release of OpenStack 2026.2 "Hibiscus" [1]. The community voted to call the 2027.1 release, "Indri". Among other things, this is the name of a rare lemur, hereinafter referred to as our favorite animal. No offence to antelopes, bobcats, caracals and dalmatians. In the past week, the OpenStack TC approved bringing the "cursive" library under Oslo [2]. The OpenDev infrastructure team pulled several stops to make this transition happen; and oslo maintainers have already begun modernizing the library. TC and PTL election nominations open in three weeks, on August 3 [3]. There are four TC seats to fill this cycle. If you know someone who'd make a good TC member, please encourage them to contest these elections. Dr. Jens Harbott (frickler) has proposed a charter change to recognize core reviewers as Active Contributors [4], which could expand the electorate. Jeremy Stanley (fungi) flagged the election tooling changes needed and we intend to act on this proposal soon, so please review and comment. Security liaison information across projects needs a refresh. If you're a PTL or DPL, please check that your project's security contact is current [5]. We have a couple of governance changes in flight to formalize this tracking [6], but the VMT needs accurate contacts regardless of whether those patches land. === Weekly Meeting === The last weekly meeting of the OpenStack Technical Committee was held on July 07, 2026 [7]. The x/cursive move was confirmed as ready to. The main discussion concerned the revival of barbican-ui. Douglas Mendizábal (dmendiza) from the Barbican project team explained that barbican-ui never really got off the ground because the core team lacks frontend expertise to review UI code. New contributors have been volunteering to revive it, but were discouraged to see the lack of reviews. We agreed that creating a separate barbican-ui-core reviewer team is a feasible path forward, so interested contributors aren't blocked by the barbican team's capacity. noonedeadpunk will seed a broader discussion on this mailing list to draw in the Horizon team, and any other interested parties. Amy Marrich (spotz) shared that OpenInfra Days North America is being planned on the sidelines of Supercomputing 2026 (November 2026) with a CFP already open [8]; details should hit this mailing list soon. The next meeting of the OpenStack TC is Tuesday July 14, 2026, at 1700 UTC. This meeting will be hosted on the #openstack-tc channel on OFTC. Please see the agenda on the meeting's wiki page [9]. I hope to see you there. === Governance Proposals === ==== Merged ==== - Add cursive under oslo | https://review.opendev.org/c/openstack/governance/+/990124 - Retire cinderlib | https://review.opendev.org/c/openstack/governance/+/994004 ==== Open for Review ==== - Seed security liaison data from VMT wiki | https://review.opendev.org/c/openstack/governance/+/996563 - Define testing runtime for 2027.1 release | https://review.opendev.org/c/openstack/governance/+/996925 - Update Telemetry release liaison to Emma Foley | https://review.opendev.org/c/openstack/governance/+/995834 - Add RISC-V | https://review.opendev.org/c/openstack/governance/+/988896 - Add security liaison tracking to projects | https://review.opendev.org/c/openstack/governance/+/993696 - Add reviewers as Active Contributors | https://review.opendev.org/c/openstack/governance/+/995535 - Retire puppet-vitrage | https://review.opendev.org/c/openstack/governance/+/996036 - Add schemas for other reference files | https://review.opendev.org/c/openstack/governance/+/993956 - Establish Contributor Experience Working Group | https://review.opendev.org/c/openstack/governance/+/994046 - Move schemas into their own directory | https://review.opendev.org/c/openstack/governance/+/993955 - Retire barbican's ansible roles | https://review.opendev.org/c/openstack/governance/+/995081 - Start testing pre-release versions for clients and libraries | https://review.opendev.org/c/openstack/governance/+/992767 - Distinguish between tested runtimes for clients and libraries | https://review.opendev.org/c/openstack/governance/+/992765 === Upcoming Events === - 2026-07-14: OpenInfra Board Meeting: https://board.openinfra.org/ - 2026-07-25: Kubernetes Community Days Vietnam 2026: https://dev.events/conferences/kubernetes-community-days-vietnam-2026-uvxfe… - 2026-07-29: KubeCon + CloudNativeCon Japan: https://events.linuxfoundation.org/kubecon-cloudnativecon-japan/ Thank you very much for reading! On behalf of the OpenStack TC, Goutham Pacha Ravi (gouthamr) OpenStack TC Chair [1] 2026.2 "Hibiscus" Release Schedule: https://releases.openstack.org/hibiscus/schedule.html [2] Add cursive under oslo: https://review.opendev.org/c/openstack/governance/+/990124 [3] How to submit a candidacy: https://governance.openstack.org/election/#how-to-submit-a-candidacy [4] Add reviewers as Active Contributors: https://review.opendev.org/c/openstack/governance/+/995535 [5] Seed security liaison data from VMT wiki: https://review.opendev.org/c/openstack/governance/+/996563 [6] Add security liaison tracking to projects: https://review.opendev.org/c/openstack/governance/+/993696 [7] TC Meeting IRC Log, July 07 2026: https://meetings.opendev.org/meetings/tc/2026/tc.2026-07-07-17.01.html [8] OpenInfra Days North America: https://linuxfoundation.regfox.com/openinfra-day-north-america [9] TC Meeting Agenda, July 14 2026: https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Next_Meeting

1 0

[kolla][upgrade][neutron] Skip OVS restart during OpenStack Kolla-Ansible upgrade?
by Shawn Ming 12 Jul '26

12 Jul '26

Hi all, We are planning to upgrade our OpenStack cluster from Antelope to Caracal. We use Open vSwitch as the networking backend and do not use OVN. To avoid network disruption, we are considering upgrading OpenStack without upgrading or restarting the openvswitch-vswitchd and openvswitch-db containers. Has anyone tried this approach? Is it safe to keep the Antelope OVS version running with the Caracal Neutron-openvswitch-agent? Regards, Shawn

1 0

[oslo][barbican][nova][glance][cinder][tc] Bringing cursive under Oslo governance
by Goutham Pacha Ravi 11 Jul '26

11 Jul '26

Hello Stackers, At the last week's TC meeting, we discussed Stephen Finucane's proposal to bring the cursive library under Oslo governance. The patches are up for formal vote: - https://review.opendev.org/c/openstack/project-config/+/990122 (repo rename) - https://review.opendev.org/c/openstack/governance/+/990124 (governance) - https://review.opendev.org/c/openstack/releases/+/993729 (releases) For those unfamiliar, cursive provides digital signature validation and is a dependency of Nova, Glance, and Cinder. It currently lives in the "x/" namespace on opendev with no active maintainers. The original authors from JHU/APL wrapped up their involvement with OpenStack back in 2018 [1]. This isn't new. Brian Rosmaita proposed the move in December 2020 [2], and Douglas Mendizábal confirmed on behalf of Barbican that he was fine with Oslo taking maintenance, offering to co-own the library similar to castellan [3]. The Oslo team agreed in January 2021 [4]. The patches just never landed. The plan is to move the repo from x/cursive to openstack/cursive and pick up Oslo's distributed leadership and release tooling.The existing cursive-core group stays intact, and there are no code or API changes. Over time, core team adjustments can be made at the behest of oslo's maintainers. I'm reaching out as a courtesy to anyone who was involved in creating or maintaining cursive. If you have concerns, please reply. Otherwise, the TC will proceed with the vote. Thanks, Goutham [1] http://lists.openstack.org/pipermail/openstack-dev/2018-July/131978.html [2] https://lists.openstack.org/pipermail/openstack-discuss/2020-December/01943… [3] https://lists.openstack.org/pipermail/openstack-discuss/2020-December/01952… [4] https://lists.openstack.org/pipermail/openstack-discuss/2021-January/019759…

2 2

[manila] 2026.2 Hibiscus Bugsquash
by Carlos Silva 10 Jul '26

10 Jul '26

Hello zorillas and interested stackers, It's time for the first OpenStack Manila bugsquash of the Hibiscus release. Next week (Jul 13th - 17th) we'll be focusing on getting closure to bugs that are in progress and waiting for that final review push to be closed. We'll do all of the work asynchronously. Vida (vhari) worked on a list of bugs [1]. How will this work? - Each of us will go through the list of bugs and add notes to the bugs that are assigned to us, as well as tag some reviewers and sign up for reviews on Monday. - We'll have an IRC chat on Tuesday, 14:00 UTC in #openstack-manila and chat about bugs that need reassignment, get closure on discussions or discuss anything related to the bugs. - We'll use half of the Jul 16th weekly meeting as a midpoint check in and talk about our progress. The idea is that we will have contributors focused on reviewing code bug fixes and addressing the comments by reviewers through the week, so we can reduce our "In Progress" bugs number and get closure for these issues. Please feel free to join us in the review festivities or add more bugs to the list. [1] https://etherpad.opendev.org/p/manila-hibiscus-m1-bugsquash Looking forward to it! Regards, carloss

1 0

[neutron] All meetings canceled next week (July 13th)
by Brian Haley 10 Jul '26

10 Jul '26

Hello Neutrinos: As discussed at our weekly meeting, all the Neutron meetings (CI, weekly, drivers) are canceled next week since we will not have quorum due to PTO and travel of team members. Meetings will resume the week afterwards. -Brian

1 0

OpenStack Private cloud for a miniature DC
by KK CHN 10 Jul '26

10 Jul '26

Hi, I have been asked to design and set up a Virtualized private cloud mini data centre environment in our small R&D development firm. Ours is an NGO. The management is given freedom to go ahead and set up this miniature data centre, obviously the option they have in mind is to procure suits like vVF or Nutanix etc etc and set up the infrastructure and services. But as a FOSS enthusiast and prior ammateur to intermediate handson experience in OpenStack and associated modules I would like to get better advice from the community members to Go-Ahead with OpenStack. * As I am not actively doing OpenStack for the last 3 years there is a gap I have in this domain and my skill set may be not uptodate. * This mini data center is going to have a couple of racks and 4 to 8 nodes at starting and external storage devices such as previously existing netapp devices that support iSCSI and FIbre, Ethernet; we don't have any SAN at this moment. *The use case scenario is to setup a mini data centre which should support : * 1. The compute workload is of virtual machines in the order of 100 to 150 in count ( Ranging from 16 to 32 vCPUs , 16 to 32 GB RAM , and 2 to 5 TB Storage for each Virtual Machine.) 2. Redundancy/Fault tolerance in case of failure of 2 to 3 nodes the system should survive and auto heal once the crashed node/disks are repaired or replaced. 3. Also want to do the virtualization of GPUs (Nvidia ) for each VM to benefit from the costly GPU in each node by GPU virtualization. To run AI workload for each VMs if required. 4. The features like live motion, redundancy in case of node failure, clone VMs on the fly etc also required. 5. Ceph based redundancy to withstand node failures / disk failures are important in our use case. If possible need to replicate the VMs/ or associated stored data in disk drives or VM volumes to geographically remote locations desirable . 6. Creation of VMs snapshots, replication of VMs based on Snapshot or bit wise replication to another remote similar setup, if possible is also desirable. 7. Overall infra management interface ( like vCentre required ) . Within my little knowledge I knew horizon dashboard is available for this purpose. Correct me If I am wrong or I have to use any other tools for more functionality like vCentre for example ? *The allotted time I have is 4 to 6 Months to Setup this environment. * To go-ahead with OpenStack, where to start and what are the components modules I need (Other than Nova, Neutron, Cinder,Swift, glance, keystone, Horizon ?) for this purpose. Any reference guide or tutorial links to setup this environment from scratch to fulfill the above requirements let me know. Someone shed some light on the order in which I have to Install each component from scratch to achieve this for a production environment. Please guide me the best way to start .. Best regards, Krishane

2 1

[security-sig][OSSN-0101] Nova console WebSocket proxy Origin allow-list poisoning
by Goutham Pacha Ravi 09 Jul '26

09 Jul '26

## Summary ## The Nova console WebSocket proxy mutates a shared, process-global oslo.config allowed_origins list on every incoming request by appending the client-controlled Host header value. Because oslo.config returns a cached list object, these appends persist for the lifetime of the proxy process. This permanently weakens the cross-origin protection on the console proxy and causes unbounded memory growth. ## Affected Services / Software ## * nova: >=12.0.0 <31.3.2, >=32.0.0 <32.2.2, >=33.0.0 <33.0.3 ## Discussion ## On each request, the proxy appends the Host header to CONF.console.allowed_origins to allow the proxy's own hostname. This mutates the shared oslo.config cached list rather than operating on a copy, so any Host value ever seen is retained permanently for the life of the process. An unauthenticated attacker can inject arbitrary hostnames into the allow-list by sending requests with crafted Host headers, defeating the Origin check for all subsequent requests. The unbounded list growth also enables a slow memory exhaustion DoS. ## Recommended Actions ## Apply the provided Nova patches. The fix copies the config list before appending, so mutations do not persist across requests. ## Patches ## The following reviews contain the fix for this issue: * 2026.2/hibiscus (development): https://review.opendev.org/c/openstack/nova/+/995870 * 2026.1/gazpacho: https://review.opendev.org/c/openstack/nova/+/995956 * 2025.2/flamingo: https://review.opendev.org/c/openstack/nova/+/995957 * 2025.1/epoxy: https://review.opendev.org/c/openstack/nova/+/995958 ## Credits ## Sergey r0binak Kanibor, Luntry ## References ## Author: Goutham Pacha Ravi, Red Hat This OSSN: https://wiki.openstack.org/wiki/OSSN/OSSN-0101 Original Launchpad bug: https://bugs.launchpad.net/nova/+bug/2158919 Mailing List: [security-sig] tag on openstack-discuss(a)lists.openstack.org OpenStack Security: https://security.openstack.org/ CVE: none

1 0

[policy] Removing the enforce_scope config option
by Ghanshyam Maan 08 Jul '26

08 Jul '26

Hello everyone, As planned in RBAC goal, the enforce_scope flag[1] was added temporarily to facilitate a smooth transition to the new RBAC and was deprecated for removal. This config was enabled by default in the 2024.2 (Dalmatian) release. As per goal timeline, we were supposed to remove this config option in 2025.2[2]. I know we are late, but I am targeting this cycle to remove this flag. What does this mean: ----------------------------- Once it is removed, the scope type will always be enforced (which is the end goal of SRBAC). If the policy rule defines the scope_type and the token does not match with that scope, then oslo.policy will raise the InvalidScope exception. Project can catch this exception and raise the modified error message similar to PolicyNotRegistered. Action item on projects: ------------------------------- 1. There are 5 projects (cinder, tacker, aetos, aodh, and barbican) that still have not enabled the scope enforcement by default (they override the enforce_Scope to false). These projects need to remove the enforce_scope override. I have proposed the change to remove it and would like to request that the project maintainer look into the changes/failure. 2. Projects need to modify their SRBAC tests because they test the scope enforcement by modifying the enforce_scope value. For example nova unit tests[3]. How to test your project: I have proposed the oslo.policy change to remove the config, and that can be used to test your project. For testing, add oslo.policy in your project jobs in 'required_project' field and depends-on the oslo.policy change (986475) oslo.policy change: https://review.opendev.org/c/openstack/oslo.policy/+/986475 nova testing change as an example: https://review.opendev.org/c/openstack/nova/+/986479 Tracking and deadline: ------------------------------ Please use the topic 'secure-rbac' and the hashtag 'remove-enforce-scope-flag' so we can track all dependencies. - https://review.opendev.org/q/hashtag:%22remove-enforce-scope-flag%22+(statu… I am targeting milestone-2 (July 3rd) as deadline to merge the oslo.policy change, make sure your project is good on removing enforce_scope. [1] https://docs.openstack.org/oslo.policy/latest/configuration/#oslo_policy.en… [2] https://governance.openstack.org/tc/goals/selected/consistent-and-secure-rb… [3] https://github.com/openstack/nova/blob/baee7c3a4f551135ca0e52fa176693a8b11a… -gmaan

3 12