- openstack-discuss - lists.openstack.org

[neutron][openvswitch] NAT + AFS = Sadness
by Jonathan Proulx 18 Nov '25

18 Nov '25

HI All, CERN may be the only other people doing anything with AFS hopefully this catches someone's eye who will just know.... The AFS filesystem use a rather "unique" connection oriented UDP protocol https://docs.kernel.org/networking/rxrpc.html This is where all our user home directories live so at's a key requirement for us. In my production cloud (mitaka sadly) we use direclty routable fixed IPs by default and all is well. In test (epoxy) we want to move away from the public v4 default IPs and lean more on floating ips for public addressing. Testing this I found impossibly poor performance for AFS behind NAT (with or without floating IP in front) on both Mitaka and Epoxy (both using openvswitch and DVR). This isn't a general NAT issue as I and others can use AFS from our homes behind comsumer NAT boxes of various sorts, and stand alone VMs out side OpenStack behind iptables based NAT are also fine. tcpdumping the connection on the fileserver sees strings of ICMP unreachable messages from the OpenStack router address (or floating ip if attahced) mid conversation. My guess is that the NAT is not maintianing stable enough port mapping becuase of the generally true assumption that UDP is stateless and will work itself out. I'm not really deeply familiar with using openvswitch for NAT as seems to be happening. Is there something I can look for in the flow rules to see what's going on? Can I tune anything to make the mappings more stable (assuming that's the issue) or am I just going to need to keep the old architecture that works? Thanks, -Jon -- Jonathan Proulx (he/him) Sr. Technical Architect The Infrastructure Group MIT CSAIL

2 4

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

18 Nov '25

Hello Stackers, We're nineteen weeks away from the date of the coordinated release of OpenStack 2026.1 "Gazpacho" [1]. Last week was Milestone 1 of this release, which project teams used to track features and bug fixes; it also served as an opportunity to ship some incremental releases across various deliverables [2]. Following up from the Project Teams Gathering, the OpenStack Technical Committee is working on Special Interest Groups within the community. The goal is to identify SIGs that need help, combine efforts, and clean up cruft in our documentation. Historically, SIGs were under the combined purview of the OpenStack Technical Committee and the OpenStack User Committee. Since these governance bodies merged in 2020, it's time to achieve more while doing less. We are combining the "governance-sigs" repository with the "governance" repository, and then auditing the SIGs and updating other outdated governance information. I encourage you to view the current SIGs [3], and if you're interested in joining an active SIG, or reforming an inactive one, please do let us know via this mailing list, or by joining the #openstack-tc IRC channel on OFTC. === Weekly Meeting === The TC met over IRC on November 11th, 2025 [4]. We followed up on action items from the recent Project Team Gathering (PTG). We added tasks to our backlog to analyze the 2025 User Survey results, and to rework the FIPS Compliance goal around testing and objectives. A new action item was assigned to clarify and document the TC's policy regarding AI/LLM contributions through the Project Team Guide. We discussed the retired project, os-net-config. The project's maintainers have removed OpenStack CI and fixed the author metadata on PyPI, as was flagged in a discussion on this mailing list [5]. There was some concern that this was problematic as it could mislead users into installing non-OpenStack-governed code without knowledge that this governance change had occurred. The consensus was that while it might be too much effort to force a PyPI name change, the TC would draft a formal resolution to retroactively acknowledge the project's handover and focus efforts on locking down PyPI access for any remaining OpenStack projects to prevent similar uncoordinated takeovers. I'll keep you posted regarding this. Wrapping up, OpenDev administrators announced the successful completion of Debian Trixie mirroring in the CI, making a DevStack job available for project teams to test with. The next meeting of the OpenStack TC is today, November 18th, 2025 at 0800 UTC. It will be hosted via IRC on OFTC's #openstack-tc channel. Please find the meeting's agenda and other details in the meeting's wiki page [6]. Please note that the TC has begun hosting a monthly meeting at this new time so we can encourage participation from folks in APAC countries. I hope you'll be able to join us there. === Governance Proposals === ==== Merged ==== - Merge governance-sigs repository into governance | https://review.opendev.org/c/openstack/governance/+/966644 ==== Open For Review ==== - Show SIG repositories on the SIGs page | https://review.opendev.org/c/openstack/governance/+/967425 - [resolution] Retire governance-sigs repository | https://review.opendev.org/c/openstack/governance/+/966645 - Retire Monasca project | https://review.opendev.org/c/openstack/governance/+/953671 === Upcoming Events === - 2025-12-09: OpenInfra Board meeting: https://board.openinfra.org/ - 2025-12-04: 2026.1 release deadline for "cycle-trailing" projects - 2026-01-08: 2026.1 Milestone 2 Thank you very much for reading! On behalf of the OpenStack TC, Goutham Pacha Ravi (gouthamr) OpenStack TC Chair [1] 2026.1 "Gazpacho" Release Schedule: https://releases.openstack.org/gazpacho/schedule.html [2] Milestone 1 releases: https://review.opendev.org/q/topic:%22gazpacho-milestone-1%22 [3] OpenStack Special Interest Groups: https://governance.openstack.org/tc/reference/sigs/ [4] TC Meeting IRC Log, Nov 11th 2025: https://meetings.opendev.org/meetings/tc/2025/tc.2025-11-11-17.01.html [5] os-net-config: https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack… [6] TC Meeting Agenda, Nov 18 2025: https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Next_Meeting

1 0

[OSSA-2025-002] OpenStack Keystone: Unauthenticated access to EC2/S3 token endpoints can grant Keystone authorization (CVE PENDING)
by Jeremy Stanley 17 Nov '25

17 Nov '25

========================================================================= OSSA-2025-002: Unauthenticated access to EC2/S3 token endpoints can grant Keystone authorization ========================================================================= :Date: November 04, 2025 :CVE: PENDING Affects ~~~~~~~ - Keystone: <26.0.1, ==27.0.0, ==28.0.0 Description ~~~~~~~~~~~ kay reported a vulnerability in Keystone’s ec2tokens and s3tokens APIs. By sending those endpoints a valid AWS Signature (e.g., from a presigned S3 URL), an unauthenticated attacker may obtain Keystone authorization (ec2tokens can yield a fully scoped token; s3tokens can reveal scope accepted by some services), resulting in unauthorized access and privilege escalation. Deployments where /v3/ec2tokens or /v3/s3tokens are reachable by unauthenticated clients (e.g., exposed on a public API) are affected. Patches ~~~~~~~ - https://review.opendev.org/966073 (2024.2/dalmatian(keystone)) - https://review.opendev.org/966067 (2024.2/dalmatian(swift)) - https://review.opendev.org/966071 (2025.1/epoxy(keystone)) - https://review.opendev.org/966064 (2025.1/epoxy(swift)) - https://review.opendev.org/966070 (2025.2/flamingo(keystone)) - https://review.opendev.org/966063 (2025.2/flamingo(swift)) - https://review.opendev.org/966069 (2026.1/gazpacho(keystone)) - https://review.opendev.org/966062 (2026.1/gazpacho(swift)) Credits ~~~~~~~ - kay (CVE PENDING) References ~~~~~~~~~~ - https://launchpad.net/bugs/2119646 Notes ~~~~~ - While the indicated Keystone patches are sufficient to mitigate this vulnerability, corresponding changes for Swift are included which keep its optional S3-like API working. - MITRE CVE Request 1930434 has been awaiting assignment since 2025-09-24, but once completed will result in an errata revision to this advisory reflecting the correct CVE ID. If any other CNA has assigned a CVE themselves in the meantime, please reject it so that we don't end up with duplicates. -- Jeremy Stanley OpenStack Vulnerability Management Team https://security.openstack.org/vmt.html

2 2

Approaches to Making Big Changes Within Our Community
by Clark Boylan 17 Nov '25

17 Nov '25

Hello everyone, There seems to be a recent sentiment within the community that the policies we've built to guide OpenStack development processes are unwieldy simply by existing. Any bureaucracy is bad by default and we should feel free to ignore it. I'd like to reject that premise and redirect some of that energy towards (what I think) is a more positive approach to making change. OpenStack has policies and procedures because it is a loose collective of many individuals and companies working towards some rough common goals. Namely the construction of a suite of software tools that interoperate to provide infrastructure as a service services. That is an incredibly broad set of goals and if we let every individual or subproject tackle this problem independently without any guidelines or constraints it would be pure chaos. Instead, over time we've built rules to help reduce the size of the problem space as we've run into fragmentation or problems that pose unnecessary overhead. For example we currently expect software to largely be written in Python, Javascript, or Go. We support Linux as the runtime platform. But we go further and list specific Linux distros that we're actually going to bother testing on. We dropped PostgreSQL support because even that was too much overhead when compared to MariaDB and MySQL. Python test tooling is currently expected to use a standard compliant test runner. Each of these examples are motivated by specific goals. Focusing on specific programming languages gives us consistency between projects so that if I need to fix a bug affecting me outside of my bubble I should have the tools to do so. Constraining programming languages also helps us build tooling around those languages to ensure that we manage packaging, security patching, translations, etc in an effective manner. Linux is a platform that largely provides all of the underlying dependencies that we need to build an infrastructure as a service system. It does so while also being compatible with our Open Source objectives. We could theoretically support OSX or Windows or FreeBSD but doing so would complicate our software and may require us to build additional tools ourselves. Constraints are good. They limit the scope of the work we have to perform which reduces overhead and hopefully produces a better result. Constraints are also important for our users and operators. Backwards compatibility is a constraint. Being able to upgrade from release X to Y is a constraint. I think the fact that we're here more than a decade after the first release with a sizeable user base is a good indicator that at least some of these constraints have been effective towards our goals. That said as time marches on our choices may no longer be in alignment with our goals and our goals may no longer be relevant. We can and should reevaluate our goals and from there reevaluate the decisions we've made. I think if we approach the process of making changes from this perspective and do so collaboratively as a community we can ensure the health of our software and community going forward. We should also probably try to be more explicit about these decisions and rely less on tribal knowledge or secret cabals. Informed developers should end up making better decisions whatever decisions are made. Finally, it probably is worth noting that this sentiment may be driven as a reaction to a community that is very resistant to change. We should be better about reevaluating our goals and decisions around those goals. Maybe this should become a regular process (either as part of the release cycle, or PTG or just annually)? The world isn't static and while some choices we made a decade ago may stand the test of time many probably do not. Let's be more open to that. Clark

3 2

[Neutron] Bug Deputy Report Nov 10- Nov 16
by Miro Tomaska 17 Nov '25

17 Nov '25

Hello All, Here is Neutron bug deputy report for November 10 through 16 *High:* https://bugs.launchpad.net/neutron/+bug/2131024 - [CI] test_add_manager related failures Rodolfo Alonso already proposed a fix https://bugs.launchpad.net/neutron/+bug/2131540 - OVN agent is not gracefully shutting down Assigned: Rodolfo Alonso *Opinion:* https://bugs.launchpad.net/neutron/+bug/2131087 Discuss with the team if port fixed-ip updates should preserve previous fixed-ips *RFE proposal:* https://bugs.launchpad.net/neutron/+bug/2131072 Neutron should publish access usage for neutron resources. Similar to Cinder volume_usage_audit *Undecided:* https://bugs.launchpad.net/neutron/+bug/2130972 - Show response body on GET enforcement request Undecided but there is already a good discussion with contributors *Incomplete*: https://bugs.launchpad.net/neutron/+bug/2131290 Looks like there is an issue connecting to OVN services... waiting for more info -- Miro Tomaska Senior Software Engineer

1 0

[watcher] Deprecate Prometheus datasource
by Joan Gilabert 17 Nov '25

17 Nov '25

Hello everyone, As discussed during the 2026.1 PTG[1], it was decided to deprecate the prometheus datasource[2] during this cycle, in favor of the aetos datasource[3]. The aetos datasource provides the same functionality as the prometheus one, but with the advantage of multi-tenancy and Kestone-based authentication. Let us know if there are any objections. A patch to deprecate the prometheus datasource is proposed[4]. [1] https://etherpad.opendev.org/p/watcher-2026.1-ptg#L207 [2] https://docs.openstack.org/watcher/latest/datasources/prometheus.html [3] https://docs.openstack.org/watcher/latest/datasources/aetos.html [4] https://review.opendev.org/c/openstack/watcher/+/966672 Regards, Joan Francesc

2 1

[magnum][all] Magnum PTG summary
by Dale Smith 17 Nov '25

17 Nov '25

Hi everyone, thanks to those who joined the Magnum PTG on 28th October. It was held early in the morning for EU, and evening for AU/NZ. Apologies to those who were less likely to make it due to the time slot; please reach out if you'd have liked to join but couldn't and we'll take that into account for the next. Attendees: 9 (6 UK/EU, 3 AU/NZ) Etherpad: https://etherpad.opendev.org/p/oct2025-ptg-magnum The floor was open to discussion topics from the etherpad, and topics were discussed in the order presented. We discussed the current state of drivers, and migration from Heat to CAPI: None planned, rebuild your clusters once CAPI is running. Cluster upgrades after that are easy. Installation of the base Kubernetes system to support CAPI drivers was a topic of interest as Magnum with CAPI drivers is now dependant on having a running Kubernetes cluster and not OpenStack Heat. This is left to deployers, but improved documentation of options and deployers would be helpful. Magnum documentation on docs.openstack.org was brought up and agreed to be in a poor state with out of date and very old references. The consensus was we should **remove** the existing documentation and rewrite it without references to Heat driver (which is deprecated and slated for removal; making this decision easier in G). Older documentation for old releases would still be available on docs.openstack.org. As with the past few cycles, the CI system needing to cover CAPI was raised. mnasiadka is planning to work on this in the G cycle. Eventlet removal patches have been created last cycle, and the core team agrees to push forward with reviewing and merging these early in the cycle so any problems can be found. and finally, discussion on a longer term feature proposals around labels[1][2] was continued with specs linked (which are noted as needing an update to current thinking). The current state of labels in Magnum is in need of an update to support more features of Cluster API; allow end users to modify these labels for a running cluster, discover valid labels, and provide a more structured format for defining these per ClusterTemplate, Cluster and NodeGroup. References: [1] https://review.opendev.org/c/openstack/magnum-specs/+/943358 Propose label normalisation spec. [2] https://review.opendev.org/c/openstack/magnum-specs/+/955549 Add spec for api-validation-with-driver -- DALE SMITH Cloud Engineer Catalyst Cloud <https://catalystcloud.nz> Aotearoa New Zealand's cloud provider e dale(a)catalystcloud.nz w catalystcloud.nz <https://catalystcloud.nz> Follow us on LinkedIn <https://www.linkedin.com/company/catalyst-cloud-limited/> Level 6, Catalyst House, 150 Willis St, Wellington 6011 Confidentiality Notice: This email is intended for the named recipients only. It may contain privileged, confidential or copyright information. If you are not the named recipient, any use, reliance upon, disclosure or copying of this email or its attachments is unauthorised. If you have received this email in error, please reply via email or call +64 4 499 2267 <tel:+6444992267>.

1 0

Neutron OVN migration
by Gk Gk 17 Nov '25

17 Nov '25

Hi Folks, I thought of sharing the below post detailing my learnings during the neutron plugin migration from LXB to OVN. Please check this out if anyone is interested. https://medium.com/@ygk.kmr/openstack-neutron-migration-from-linux-bridge-t… Thoughts, comments, opinions are welcome including criticism.. Thanks Kumar

2 2

[release] Release countdown for week R-19
by Thierry Carrez 14 Nov '25

14 Nov '25

Development Focus ----------------- We are now past the gazpacho-1 milestone. Teams should now be focused on feature development and completion of goals [0]. [0] https://governance.openstack.org/tc/goals/selected/index.html General Information ------------------- Our next milestone in this development cycle will be gazpacho-2, on January 8, 2026. This milestone is when we freeze the list of deliverables that will be included in the 2026.1 "Gazpacho" final release, so if you plan to introduce new deliverables in this release, please propose a change to add an empty deliverable file in the deliverables/gazpacho directory of the openstack/releases repository. Now is also generally a good time to look at bugfixes that were introduced in the master branch that might make sense to be backported and released in a stable release. If you have any question around the OpenStack release process, feel free to ask on this mailing-list or on the #openstack-release channel on IRC. Upcoming Deadlines & Dates -------------------------- gazpacho-2 Milestone: January 8, 2026 -- Thierry Carrez (ttx)

1 0

[Kolla] Transition Antelope (2023.1) to End of Life
by Bartosz Bezak 14 Nov '25

14 Nov '25

Hello, The Kolla Antelope (2023.1) deliverables - Kolla, Kolla-Ansible, Kayobe and Ansible-Collection-Kolla - are being moved to end-of-life (EOL) status. [1] Antelope has been in the unmaintained state for some time, and the Kolla community does not have the resources to support it further. There are no active changes for Kolla project deliverables in the Antelope branches. [2] In line with other OpenStack projects, Caracal (2024.1) will also be marked as unmaintained soon. Dalmatian (2024.2) and Epoxy (2025.1) are currently our supported stable releases. Flamingo (2025.2) is expected to be released in the coming weeks. [1] https://review.opendev.org/c/openstack/releases/+/967217 [2] https://review.opendev.org/q/project:%22%5Eopenstack/(ansible-collection-ko… Best regards, Bartosz Bezak

1 0