- openstack-discuss - lists.openstack.org

[neutron] Drivers meeting canceled Friday, November 14th
by Brian Haley 13 Nov '25

13 Nov '25

Hello Neutrinos: I am going to cancel tomorrow's Drivers meeting as I will be out. Just a reminder that our open spec list at [0]. Have a nice weekend! -Brian [0] https://review.opendev.org/q/status:open+project:openstack/neutron-specs

1 0

[OpenStack Ansible] [Deployment] Networking design issue
by holywine＠outlook.com 12 Nov '25

12 Nov '25

Hello, [Following up a previous unfinished case/task with an enhanced network] I am trying to build a minimum usable production-level cloud with OpenStack Ansible following online reference. (https://docs.openstack.org/project-deploy-guide/openstack-ansible/2025.1/) openstack-ansible version: stable/2025.1 4 servers as target hosts, all with Ubuntu 24.04LTS. Each server has two Ethernet ports enp11s0f0, enp11s0f1. All servers’ enp11s0f1 ports has a fixed public IP (10.2.46.XX/24) and has access to Internet. All servers’ enp11s0f0 ports are intended to be used for OpenStack traffic. They are assigned IP range in 172.29.XX.XX for internal use. The idea of design: 1) Infra1: Controller 1 + networking 1 2) Infra2: Controller 2 + networking 2 3) Compute 1: Compute 1 + networking 3 + storage 1 4) Compute 2: Compute 2 + networking 4 + storage 2 Reference: The network topology and the deployment configuration (including user_variables.yml and openstack_user_config.yml) for a trial run can be found: https://github.com/holywi/git-tutorial/tree/master While, with this setting the deployment always failed by reporting errors seems to be related to HAproxy. I am wondering it is related to network design and services assignment. It would be grateful if anyone can provide some comments, suggestions or some common practices for the similar case. Some questions have popped up in my mind: 1) Does it make sense to make each host to access Internet on its own? It seems possible since each server has dedicated port and Openstack can support local routers? If not, how can these servers access Internet? 2) Is it good to make all 4 hosts the HAproxy server? 3) If using an FQDN for internal_lb_vip_address (it seems to be the case in the reference config) where the DNS server is located and how to make it happen? I don't see any setting which is related to DNS and DHCP which seems to be useful as well. Highly appreciate for any feedback as a new comer for Openstack.

1 0

OpenStack Student Engagement, University Partnerships, & Mentors
by Kendall Nelson 12 Nov '25

12 Nov '25

Hello Everyone, You might have noticed a non zero number of my emails to the mailing list have to do with the University Partnership Program <https://openinfra.org/university-partnership-program/> and engaging with universities to get students involved in OpenStack (and generally open source). Usually these emails are per university/opportunity which is rather inefficient and all too often I end up being a bottleneck in the process. At the PTG, during one of the Technical Committee sessions I shared an etherpad <https://etherpad.opendev.org/p/UPP-Projects%26Mentors> that I am hoping to utilize to smooth the whole process. The intent is to collect possible projects up front that I can share with professors as they reach out to me. I take responsibility for regularly auditing the project list so it doesn't become stale. Potentially this collection + audit could be a PTG session at future PTGs, but that doesn't have to be decided now. You will notice in the etherpad, that I also have a place for just collecting folks interested in being mentors. If you don't currently have an idea for a project, but are interested in mentoring, please add your name to that section. This list will also get regularly refreshed, but I am thinking on a yearly basis instead of twice a year - that said, nothing is stopping you from adding or removing your name in between those audits. I am 100% open to feedback on this, but it will hopefully allow more folks interested in participating in the University Partnership program and help smooth out the process for involvement. If you want to get involved either as a mentor or with a specific project proposal for students, please add to the etherpad ASAP <https://etherpad.opendev.org/p/UPP-Projects%26Mentors>! I expect a round of professors reaching out in the next month for students starting their terms in early January (usually running through late May). Please let me know if you have any other questions I might have missed. And thank you to everyone that made it through this lengthy email :) -Kendall

1 0

[all][keystone] Keystone PTG summary
by Artem Goncharov 12 Nov '25

12 Nov '25

Hey guys Let us give you an update of the OpenStack Keystone future following the great PTG week we just had. Some news has already spread across the community, causing excitement and anxiety. It is not uncommon that changes cause fear. Some time ago, in the age of the Inquisition, people were even burned because of fear, misunderstanding, or questioning the rules. Let us clarify things. Nearly 13 years ago, the Identity v3 API was introduced. Since then, the world has changed dramatically. Libraries we use got abandoned, standards went legacy and replaced with new ones, ecosystem components, certain functionality is based upon are being sunsetted by OS vendors (mod_auth_mellon is archived upstream and gone in CentOS and RHEL [6]), new security vulnerabilities (classes of vulnerabilities) appear like mushrooms without us being able to address them. Cloud providers today face new challenges that were not present 10-15 years ago. Nowadays, a public cloud requires proper federation support with complete self-service. Users request passkey support, and security departments require additional hardening. These things cannot be covered in today's Keystone architecture and API version. As a result, work on an optional extension to Keystone [1] began some time ago, allowing CSPs to deploy it in parallel with the Python Keystone (of any v3 version) and access the new features. To simplify parallel deployment, it has been decided to start introducing v4 with the new features (since those ARE for cloud end-users). The work was done in Rust due to multiple factors: lack of necessary python libraries with trustable maintenance and/or licensing, necessity for enforcing security standards and practices using memory safe programming language, demand to address python ecosystem madness of past years (I guess majority would agree, that in the past few years we were mostly only chasing the python ecosystem breaking us on setuptools, eventlet, passlib, …). During the work, it became clear that implementing the mentioned features requires support of a given percentage of the existing functionality: users, groups, projects, roles, and tokens. And so it was implemented. A side effect of it became immediately visible: performance. Token check is THE most frequently called API in the OpenStack cloud. Right now, caching is used to reduce system stress. But in Rust, token decryption, without caching, is much faster than in python with caching (we expect a 2-3x faster order of magnitude). As mentioned above, new vulnerability classes and attack vectors require us to disable caching, making such an improvement highly valuable. The new stack is fully async, uses parallel DB queries, and runs background tasks for periodic cleanups, synchronization, and similar. This allows us to achieve significant performance and maintainability improvements, eliminate the old ballast, and significantly reduce transitive dependency version conflicts. Current measurements also indicate that we would likely be able to eliminate the need for caching in Keystone. For python, on the other hand, we do not have much to start with and would need to find and migrate to the new web framework, find maintained libraries with suitable licenses, and implement new features. We also need to rework the DB access patterns due to the number of bugs and the performance penalty caused by suboptimal DB access (many rows are selected multiple times during processing of a single request). With new authentication flows, we would need to do a wide security assessment of Keystone from scratch anyway. With that work in mind and facing the prospect of having a major rework in python Keystone anyway (due to the abandoned complex dependencies), we, as the Keystone team, decided to try to focus the work on the Rust implementation, making it a proper evolution of the python Keystone and building a necessary community around it. This adoption is conditional on adding new contributors to support the project. We believe this approach allows the best of both worlds: the trusted maturity of Keystone’s Python code-base, combined with the modern, high-safety, high-performance capabilities of Rust where they matter most. Logically, this raises questions, so let's try to answer some of them: 1. Rust is not officially allowed in OpenStack. How are you dealing with that - The development is now going on on GitHub outside of OpenStack governance. - We would apply for OpenStack universe inclusion. - Once the TC policy allows Rust or the overall project inclusion requirement is reworked, the project will work toward becoming the official OpenStack project. - No one in the team is willing to separate from OpenStack, but with the current policies, we have no other way. Everybody and everything in the OpenStack ecosystem would benefit from that project being official to have first-class native support of the new functionality. - Multiple CSPs expressed support for such a move, desiring to see Rust in the ecosystem for better performance, maintainability, and resource utilization - A nice coincidence is a freshly sent announcement from Debian that introduces a strong rust dependency in the packaging tooling, stating something similar to: either you work to comply with this requirement in the next 6 months or sunset the port [5]. - Rust allows cross-integration with python with a high number of cryptography and typing libraries for python written directly in Rust. We are going to be able to reuse certain pieces of python in Rust during porting and Rust in python later in the future. - Keystone is a very sensitive component and in our eyes that fully justifies use of rust to provide a much stronger security on the language level. 2. Do you deprecate python Keystone. - No - v3 is there, and we continue maintaining it - We would unlikely accept major changes - Keystonemiddleware, keystoneauth, etc, are still there. They would likely be adopted for v4 support at some point in the future (in OpenStack services, we already communicate with “external” software, so there should be no problem). Those libraries are crucial for other services and thus are there to stay while necessary. - At some point, we will no longer be able to keep it alive when abandoned dependencies are physically gone. We are not going to invest our time in maintaining the abandoned software; we do not have enough time to do so. 3. What is the community around it? - As of now, there are provisional commitments from a few vendors and CSPs to collaborate on it. - Existing software is being transferred under the openstack-experimental organization to help build the community [3]. -The initial author (gtema) personally commits to continue working on that independently of others. 4. What are the /v3 features that would go away? - OIDC federation in its current form. v4 reimplements it from scratch natively without depending on external software (mod_auth_oidc, etc) since those make self-service impossible. - Saml2, this is a legacy protocol that is very unlikely to even get fixes for security vulnerabilities, and looks to be PQC unsafe. - Oauth1. 5. What new features are there in v4? - OIDC with self-service and CLI integration - Workload federation (Zuul, GitHub, Gitlab do not need to have secrets to access OpenStack anymore) - Service accounts (many use cases, one of the prominent ones: OpenStack on Kubernetes, GitHub workflow) - Passkeys (webauthn) - SCIM - Tight Open Policy Agent integration. We plan to consider the reintroduction of central policy storage in Keystone (not enforcing, but for central storage)[4] We will use the next 2-3 months to gather interest in contributing to this approach and the new Rust-based code. There was a lot of interest in the new features listed right above during gtema’s sessions in OpenInfra Summit in October 2025. Still, it has to translate into active contributors for this effort to take off. If you have an interest in those new features, join us! We hope this clarifies the situation. Feel free to reach out with other questions. Thanks to everybody who participated in the discussions. Regards, Keystone team [1] https://github.com/gtema/keystone [2] https://www.youtube.com/watch?v=XOHYqE2HRw4&list=PLKqaoAnDyfgr91wN_12nwY321… [3] https://github.com/openstack-experimental/keystone [4] https://www.youtube.com/watch?v=_B4Zsd8RG88&list=PLKqaoAnDyfgr91wN_12nwY321… [5] https://lists.debian.org/debian-devel/2025/10/msg00285.html [6] https://access.redhat.com/solutions/2743391

10 20

[oslo][all] Proposing oslo.wsgi
by Stephen Finucane 12 Nov '25

12 Nov '25

o/ I'd like to propose the creation of a new "oslo.wsgi" project that service projects should adopt, where it makes sense to. My reasons for this proposal are three-fold: * As we've been working on the OpenAPI work for various services, we've found ourselves copy-pasting a lot of the code between these services. This has occasionally led to issues when those copies are incomplete [1][2]. Historically speaking, copy-pasting of code between services is a sure sign that this code should be generalised and placed in an oslo library * I have previously noted [3] that oslo.service contains some non- eventlet-related WSGI routing code, and there are questions around whether (a) that code should have been placed there in the first place and (b) how we can maintain that long-term once the eventlet code is removed (the 'oslo_service.wsgi' module has side effects since it imports the backend configuration stuff). * I have also raised some concerns around our use of paste.deploy and routes [1], both of which are minimally maintained nowadays. Many oslo libraries are designed to abstract their underlying libraries, allowing users to switch between e.g. different messaging backends (oslo.messaging) or caching services (oslo.cache). Taken together, I think now would be a good time to provide a new library. I have an initial prototype available [4] which is effectively just a refactoring of the code from oslo.service, but I expect to add both more functionality to this existing code from existing consumers (Nova, Manila, Cinder etc.) and to add the openapi validation machinery. I imagine longer-term, this should evolve to allow us to replace the underlying libraries. However, we should obviously not get into the business of writing our own web framework. I also don't think it would make sense for all services to adopt all aspects of this project, since not all projects have any OpenAPI efforts ongoing at the moment and not all of them use the pastedeploy-routes-webob combo. Given the above rationale and caveats, what do people think? Are there any objections to this idea? Please let me know. If there is not, I will go figure out how to get the ball rolling on this. Cheers, Stephen PS: Why oslo.wsgi instead of a more generic name like debtcollector or futurist? I don't think this library will be useful outside of OpenStack, so the oslo prefix makes sense. [1] https://review.opendev.org/c/openstack/ironic/+/963938 [2] https://review.opendev.org/c/openstack/ironic/+/960291 [3] https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack… [4] https://github.com/stephenfin/oslo.wsgi

8 13

[watcher] 2nd call for maintainers - MAAS integration
by Douglas Viroel 12 Nov '25

12 Nov '25

Hi all, The Watcher team had a session[1] during the last PTG about the impacts of service integrations that have lacked maintainers, documentation, and/or testing coverage in CI. The MAAS (Metal As A Service) integration still lacks maintainers and is impacting the eventlet removal effort within Watcher, since it contains eventlet-dependent code that requires maintenance and validation. In the 2025.2 development cycle, we had a first call for maintainers[2] and we didn't receive any feedback. This is a second call for maintainers interested in supporting MAAS in Watcher, to help fill these gaps (eventlet removal, CI testing, documentation). The Watcher team plans to *deprecate* this integration during the 2026.1 cycle if we don't find anyone to assist in maintaining it. [1] https://etherpad.opendev.org/p/watcher-2026.1-ptg#L177 [2] https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack… Thanks and regards, -- Douglas Viroel - dviroel

2 1

[Kolla-Ansible][Tacker] [VIM]Unable to find key file for VIM
by josem.arco＠uah.es 12 Nov '25

12 Nov '25

Hi All, I have installed an bare-metal server Ubuntu 24.04 with Kolla-Ansible and all-in-one with Tacker. When I register the OpenStack Vim with the CLI I have this error “Unable to find key file for VIM e255b2e2…”. I have tried with the two optios of the 'cert_verify' parameter but it doesn’t work. I have also tried to do it with Horizon and it says “Error: Failed to register VIM. Details The request you have made requires authentication.” I have followed the lastest web pages of Kolla and Tacker. Thanks in advance for your help. Jose

1 0

Add Trait requirement to running Instances
by Kees Meijs | Nefos 12 Nov '25

12 Nov '25

Hi list, We're looking for a method to add Trait requirements to already running Instances, forcing certain placement upon resize or migration of them. Is there a clean way to do this? Or is there database surgery (which is acceptable to some extend) needed, and how? Thanks! Cheers, Kees __ Kees Meijs BICT Nefos Cloud & IT <https://nefos.com/contact> Nefos IT bv Burgemeester Mollaan 34a 5582 CK Waalre - NL kvk 66494931 +31 (0)88 2088 188 <tel:+31882088188> nefos.com <https://nefos.com/contact> The information contained in this message is intended for the addressee only and may contain classified information. If you are not the addressee, please delete this message and notify the sender; you should not copy or distribute this message or disclose its contents to anyone. Any views or opinions expressed in this message are those of the individual(s) and not necessarily of the organization. No reliance may be placed on this message without written confirmation from an authorised representative of its contents. No guarantee is implied that this message or any attachment is virus free or has not been intercepted and amended. General terms and conditions ("The NLdigital Terms") apply to all our products and services.

2 2

[all] PSA: requirements-check job no longer normalises underscores with hyphens
by Stephen Finucane 12 Nov '25

12 Nov '25

o/ Sean Mooney noted earlier today that watcher's requirements-check job has started failing with the following warning: Validating requirements.txt WARNING: possible mismatch found for package "microversion_parse" Attribute "package" does not match "microversion_parse" does not match "microversion-parse" Requirement(package='microversion_parse', location='', specifiers='>=0.2.1', markers='', comment='# Apache-2.0', extras=frozenset()) Requirement(package='microversion-parse', location='', specifiers='', markers='', comment='# Apache-2.0', extras=frozenset()) ERROR: Could not find a global requirements entry to match package microversion_parse. If the package is already included in the global list, the name or platform markers there may not match the local settings. This is almost certainly due to recent changes in the openstack/requirements repo to remove use of the soon-to-be-removed pkg_resources library [1]. Its replacement for this use case - packaging - does normalisation slightly differently and it seems it doesn't replace underscores with hyphens. While this could be fixed with custom normalisation in the requirements repo, I don't believe it's wise to do so as that custom normalization would need to be copied anywhere else that needs to parse OpenStack requirements.txt files and requirements more generally. I would instead encourage affected projects to fix the names used in their various requirements.txt files and use the correct PyPI names. From a quick look at failing requirements-check jobs in recent days [2], there aren't many: I see neutron has already fixed the issue [3] and I've proposed a fix for tap-as-a-service [4]. Those patches should prove how small a task this should be. Hope this helps, Stephen [1] https://review.opendev.org/c/openstack/requirements/+/960845 [2] https://zuul.opendev.org/t/openstack/builds?job_name=requirements-check&res… [3] https://review.opendev.org/c/openstack/neutron/+/965188 [4] https://review.opendev.org/c/openstack/tap-as-a-service/+/966782

2 1

List Limits returns Null in Nova Unified Limits
by Tyler Wilson 11 Nov '25

11 Nov '25

Hello All, I'm looking into testing out the Nova unified limits, however I am experiencing an odd issue where the 'limit list' returns no data. The 'limit create' and 'limit show' (with the UUID from the create command) seem to work fine. Paste data for the output is here: https://pastebin.com/sPZgZDEK I've even tried sending a GET to http://KEYSTONE_IP:5000/v3/limits with the output of [] ({"limits": [], "links": {"next": null, "self": "http://KEYSTONE_IP:5000/v3/limits", "previous": null}}) The log in keystone WSGI just shows a 200 for the GET request, not much else I could find. Should this work in the way I am expecting here? Or am I missing something? Thanks for any and all assistance!

2 5

[cinder][PTG] 2026.1 Gazpacho PTG summary
by Jon Bernard 11 Nov '25

11 Nov '25

Hello everyone, thanks for a very productive PTG for the Gazpacho cycle. Below is a brief summary of the highlights. The raw etherpad notes are here [1] and both the summary and transcribed etherpad notes are captured in out wiki here [2]. # Retrospective We spent time discussing the good and not-so-good of the flamingo cycle. Unsurprisingly, code reviews continue to be our most significant opportunity for improvement. We reviewed what a core reviewer is and how to work towards becoming one, including the metrics that we use to determine eligibility and what we look for in a potential core reviewer. I encourage anyone interested in contributing the project to reach out, in addition to our guideline document on the review process, we're happy to answer questions and help guide folks through the process. # Festival of Reviews We are reworking our 'festival of reviews' meeting to better accommodate a larger set of potential patches. Previously it focused on very small patches that were easier to review, but feedback suggests that time spent as a team on larger reviews would yield a more desirable result. Last Friday we ran the modified format and it seemed to work quite well. # 3rd Party CI This cycle 3rd party CI is required for patches to be reviewed. In the flamingo cycle we saw some challenges with deploying and configuring the software factory setup required to operate a CI. We remain committed to helping vendors sort out any remaining problems, and want to avoid any further slipping on our requirements, as one-off exceptions do not scale. # Eventlet Removal There will be significant focus this cycle on the removal of eventlet from our codebase. Our goal is to have this work completed before M2. The remaining issues and technical challenges were discussed, including some struggles with our multi-backend and it's use of sqlalchemy. We learned that the oslo team is working on some code that may help with this effort. We may have finally found a use for the rally job, unfortunately it has been broken for some time, we will try to get this fixed and reporting useful results this cycle as well. # Driver Block Geometry An original patch to the RBD driver was proposed to make configuring block geometry an option for the operator. Upon inspection, we decided make this option available for all drivers. Discussion about exact location given out driver class model, we have a way forward. https://review.opendev.org/c/openstack/cinder/+/658283 # Per-Tenant SVM Creation Doug Goldstein showed up and blew our minds with a proof-of-concept feature he added to the NetApp driver. This change allows the driver to create per-tentant SVMs and map them to dynamically created backends. There will be some technical hurdles to overcome, but the idea in theory could work. Doug is going to work to propose a patch upstream and with the NetApp team to see if it can take shape. # OpenAPI Stephen has had patches up for openAPI compliance for far too long. We don't have any technical objections to the effort. Brian and I committed to working through the proposed patches at the very start of the cycle. Significant progress already, should be completed soon. # Reverting To Any Snapshot Currently you can only roll a volume back to the last available snapshot. We would like to be able to select any snapshot as a rollback target. Technical requirements were discussed, including the need for a spec. Hoping to see progress on this effort in this cycle. # Clone Across Pools We are interested in improving our implementation for cloning a volume across different pools. The code itself has some distinct shortcomings and Rajat identified several opportunities for improvement. Feedback on current usage was requested, we discussed volume caching as part of these improvements. A path forward was defined and spec should follow. # NFS Driver Feedback Fernando has been working on several improvements to the generic NFS driver and requested feedback. NetApp offered valuable suggestions, some improvements to our tempest testing patches are forthcoming, and a direction forward is understood. # Replication Feedback We solicited feedback on replication, its current usage, and the features it may require to see wider adoption. Questions and answers were discussed, hoping to see a spec capturing the most valuable changes in this cycle. [1] https://etherpad.opendev.org/p/cinder-gazpacho-ptg [2] https://wiki.openstack.org/wiki/CinderGazpachoPTGSummary -- Jon

1 0

[ironic] [all] Ironic PTG Summary
by Jay Faulkner 11 Nov '25

11 Nov '25

Hi all, The Ironic team had another successful PTG planning our 2026.1 release. As usual, we've published a summary of the discussions into the work items document we'll be referencing throughout the year. https://specs.openstack.org/openstack/ironic-specs/priorities/2026-1-workit… If you'd like more in-depth detail as to discussions, please review the etherpad for the PTG at https://etherpad.opendev.org/p/ironic-ptg-2026.1 -- everyone is also welcome to respond here or come join us in OFTC #openstack-ironic to discuss any of these items if needed. Thanks, Jay Faulkner G-Research OSS

2 2

[PTG] Call for Summaries, Attendance Numbers, and Team Photos
by Kendall Nelson 10 Nov '25

10 Nov '25

Hello Folks! I am working on a summary post for our OpenInfra Blog as usual and I am missing A LOT of attendance numbers from OpenStack teams. Specifically, I am missing attendance numbers from: - Barbican - Blazar - Cinder - Cloudkitty - Cross Deploy - Designate - Eventlet Removal - Glance - Heat - Horizon - i18n - Ironic - Keystone - Kolla - Magnum - Neutron - OpenStack Ansible - OpenStack Helm - Sunbeam - Swift - Tacker - Telemetry - Watcher If you were a moderator for this session please send me your approximate attendance to ptg(a)openinfra.org ASAP. If you simply attended one of these sessions, and you would be so kind as to remind the moderator to send me the info I would be very grateful! Additionally, I will happily accept any team photos that were taken and links to blog posts or other summaries that I can include in OpenInfra Blog post as well. There are a lot of open source communities outside of the OpenInfra Foundation that are curious about how we conduct our PTGs and these posts are incredibly helpful at educating others on how to follow the four opens and build a stronger community. Thank you for all of your support! Looking forward to the next PTG! -Kendall

2 3

[nova]Migrating instances with anti-affinity rules causes them to enter ERROR state
by Nguyễn Hữu Khôi 10 Nov '25

10 Nov '25

Hello, I have two instances of an anti-affinity rule. When I move instance a to the host which contains instance b then instance a enters error state. It will be nice if we keep instances at source compute and notify. My env: Openstack 2025.1 Ubuntu 24.04 Nguyen Huu Khoi

1 0

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

10 Nov '25

Hello Stackers, We are twenty-one weeks away from the date of the coordinated release of OpenStack 2025.2 "Gazpacho" [1]. Next week is Milestone-1 of the release. This is typically a bug and feature tracking milestone for project teams. Hope you have been catching up on all the post-PTG action from the past week on this mailing list and on IRC. The OpenStack Technical Committee's PTG summary was shared as well [2]. We are hoping to check on the pending items through our weekly meeting. In the past week, the Telemetry team welcomed back Juan Larriba (jlarriba) as its PTL for the current release cycle. There have been no other governance updates from the OpenStack Technical Committee to report, however, we are looking to close out a long list of pending changes to fully retire the Monasca project [3]. === Weekly Meeting === The last weekly meeting of the OpenStack TC occurred on November 4th 2025 in the #openstack-tc channel on OFTC [4]. It was quite brief since we were still recovering from all the sync meetings from the Summit and the PTG week. We covered the follow-up from the awesome APAC/EU-friendly TC meeting and realized we need to nail down some owners for the user survey action items that we took. We noted that the deadline for getting new questions in for the next survey is December 1st 2025. We had a good discussion about tracking and preserving project PTL appointment history on the governance repository. On the CI front, we hit a brief Gerrit outage, likely caused by an OOM issue that one of our generous providers, Vexxhost, was looking into. OpenDev administrators were working through a Zuul bug that is causing multinode jobs to jump between providers. We also noted the transition of the "stable/2024.1" branch to "unmaintained/2024.1" - this transition affected all repositories that contained the stable/2024.1 branch. A link to a discussion on the CRA (Cyber Resilience Act) was shared [5], with a prevailing interpretation being that individual open source contributors/maintainers have no legal obligations under it. Overall, this was a light meeting, but things are about to get heavy once we digest all the PTG takeaways. The next meeting of the OpenStack TC is on November 11th 2025 at 1700 UTC. It will be hosted on the #openstack-tc channel on OFTC. The agenda for this meeting is on the meeting's wiki page [6]. I hope you will be able to join us. === Governance Proposals === ==== Merged ==== - Propose jlarriba to Telemetry PTL | https://review.opendev.org/c/openstack/governance/+/964516 ==== Open For Review ==== - Retire Monasca project | https://review.opendev.org/c/openstack/governance/+/953671 === Upcoming Events === - 2025-11-10: KubeCon NA: https://events.linuxfoundation.org/kubecon-cloudnativecon-north-america - 2025-11-15: Celebrating 15 years of OpenStack, Montréal: https://www.meetup.com/montreal-openstack/events/310374679/ - 2025-11-15: KCD + OpenInfra Days, Hangzhou: https://sessionize.com/kcd-hangzhou-and-oicd-2025/ 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] OpenStack TC PTG Summary: https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack… [3] Monasca Retirement: https://review.opendev.org/q/hashtag:%22monasca-retirement%22+(status:open%… [4] TC Meeting IRC Log, Nov 4th 2025: https://meetings.opendev.org/meetings/tc/2025/tc.2025-11-04-17.00.html [5] CRA update: https://lists.openinfra.org/archives/list/foundation-board@lists.openinfra.… [6] TC Meeting Agenda, Nov 11 2025: https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Next_Meeting

1 0

[ironic] Proposed: Reviewer & Approver team updates
by Jay Faulkner 10 Nov '25

10 Nov '25

Ironic approvers had a discussion about the current state of the core team, and we propose the following changes. As some context for those not familiar, Ironic has two review groups: - Ironic-Approvers -- this group has the ability to +2 changes and Workflow +1 changes - Ironic-Reviewers -- this group has the ability to +2 changes, but cannot Workflow +1 changes I am proposing the promotion of our two inaugural members of ironic-reviewers into approvers. Both of these contributors have used their +2 judiciously and have earned the trust of the community to use that same judgement about which changes to approve: * Afonne-CID (cid) from GR-OSS (move from ironic-reviewer to ironic-approver) * Doug Goldstein (cardoe) from Rackspace (move from ironic-reviewer to ironic-approver ) Additionally, we'd like to add an existing community member to ironic-reviewers. Jakub Jelinek has become the community expert on RAID support in IPA and has deepened his knowledge across the codebase. We'd like to recognize that by asking him to join the ironic-reviewers team. * Jakub Jelinek (kubajj) from CERN (add to ironic-reviewer) Finally, we would like to move an existing ironic-approver and longtime contributor to emeritus status. Mark Goddard is no longer active in the OpenStack community, and I propose he be moved to emeritus status. This just means that while he may be removed from the team, if at some future point he returns to the Ironic community we may expedite his return to the approvers group. * Mark Goddard (remove from ironic-approvers) Thanks everyone for your contributions to Ironic, current and future. It's nice to see the growth of the team, and hope this opens the door for CID, cardoe, and kubajj to grow themselves and the team further. Thanks, Jay Faulkner G-Research OSS

4 4

[Nova] Spec Soft Freeze Approaching November 20!
by René Ribaud 10 Nov '25

10 Nov '25

Hi everyone, Time really flies, we’re already approaching the Nova Spec Soft Freeze for the Gazpacho cycle! Just a quick reminder that after November 20, 2025 (23:59 UTC), no new specs will be accepted. If you’re currently working on a proposal or reviewing one, now’s the time to propose it. Let’s make the most of the remaining days, and thank you all for keeping the momentum going! Cheers, René

1 0

[openstack-ansible] Bug fighting day - Save the date
by Dmitriy Rabotyagov 10 Nov '25

10 Nov '25

Hi everyone, This week, on Thursday, *November 13*, we are going to hold our yearly bug-fighting day. We plan to start active work around *1:00 PM UTC*. The activity aims to gather all Core Reviewers along with interested community members to join forces to review, triage and propose patches to as many bug reports as possible. This should contribute towards project stability and reduce the amount of issues in the project codebase. We invite everyone interested to participate to join our #openstack-ansible IRC channel on OFTC network. Alternatively, you can join the room #_oftc_#openstack-ansible:matrix.org with your Matrix (Element) account. We are going to use an Etherpad [1] to work in an asynchronous way and to ensure that different people will not be working on the same bug reports. Please sign in in the Etherpad [1] participants list before starting the work, so we could estimate participation and scope we can pull during the day. [1] https://etherpad.opendev.org/p/osa-nov-2025-bug-triage

1 0

[openstack-ansible][ptg] 2026.1 Gazpacho Summary
by Dmitriy Rabotyagov 10 Nov '25

10 Nov '25

Hi everyone. OpenStack-Ansible team has held a PTG session, where discussed left scope before 2025.2 (Flamingo) Release as well as development scope for 2026.1 releases. For 2025.2 we agreed to finalize these topics: - Debian 13 (Trixie) support - Fix playbooks to address ANSIBLE_GATHER_SUBSET removal in ansible-core 2.18 - Finalize OpenBao backend for the PKI role As I am writing a summary late this time, 2 out of 3 topics (Debian 13 support and ANSIBLE_GATHER_SUBSET replacement) have already been concluded. With that being said, we move couple of topics to 2026.1 (Gazpacho) cycle, specifically: - Mainstreaming Magnum CAPI drivers (promoting from ops repo to the integrated one) - Molecule coverage for the HAProxy role For the 2026.1 (Gazpacho) release cycle, the following topics were raised: - Improving MariaDB proxying and introducing read/write balancing. Originally we agreed to adopt ProxySQL, as we had plans for that since the Xena release, but it was never prioritized. Now we've realized that there is a possibility to leverage oslo.db's `slave_connection` parameter, which should be quite trivial to add, while providing similar behavior with just HAProxy balancing. - Big topic was adoption of ansible-core 2.19 and related challenges with role patching as well as our custom modules adoption to it. And we agreed to prioritize this work, as ansible-core 2.18 goes EOL in May 2026. - Once HAProxy role will be covered with molecule tests, we agreed to proceed with potential role refactoring, and removing obscure variables and parameters. Specifically, frontend definition is a focus, as it has some legacy, which prevents it being flexible enough for 3rd-party usage of the role. - With that we highlighted existing complexity regarding non-TLS -> TLS migrations, but uWSGI remains a blocker to move to TLS-only deployments, as HTTP 1/1 remains to be a bottleneck in terms of throughput. - We agreed to proceed to refactoring a standalone method for PKI role, and remove the necessity of storing individual certificates and private keys on the deploy host. - Attempt to add Ubuntu 26.04 support for 2026.1 Gazpacho - We touched basis on post-quantum encryption and figure out dependencies and blockers for that. With Debian 13 and Ubuntu 26.04 we will have OpenSSL 3.5, which supports already ML-KEM. However, a bunch of software, like uWSGI are still gonna be blockers to implement PQC deployment-wise. Support for things like RabbitMQ, MariaDB and etc remains unknown.

1 0

[ops][largescale-sig] Refactoring Ops-related activities - a discussion at the PTG
by Thierry Carrez 10 Nov '25

10 Nov '25

Hi everyone, A quick reminder that we'll have a session at 13:00UTC today in the PTG on how we can regroup the operators-facing activities between our various groups: the Ops meetup group, the Large Scale SIG, the Public Cloud SIG, the Scientific SIG... Join us if you can! -- Thierry Carrez (ttx)

2 2

LXB Removal and OVN migration
by Ricardo Cano 09 Nov '25

09 Nov '25

Hello openstack-discuss, With the removal of the linuxbridge mechanism driver, has anyone successfully completed an in-place migrationfrom LinuxBridge to OVN? I did come across this https://www.jimmdenton.com/migrating-lxb-to-ovn/ and that looks good as a one-shoit while biting the bullet and taking a full outage. However, I was wondering if it was possible to run lxb and ovn side-by-side and cut them over, say one network at a time. This particular deployment was stood up using openstack-ansible back in the rocky days (now running antelope) and it appears that openstack ansible's default was lxb up until Zed. Any suggestions or recommendations on the best path forward? Also, will the dynamic routing agent work with ovn?

4 3

[openstack helm] [Glance] Glance showing OSError: unable to receive chunked part when uploading image
by daniel890723＠gmail.com 08 Nov '25

08 Nov '25

Hello i'm testing using Openstack-helm to install all component but after the installation complete i can't upload the OS image through both openstack CLI or Horizon it stuck at Queueing and when i checking Glance Api log it shows 2024-11-07 07:31:19.362 7 INFO glance.api.v2.image_data [None req-2bd28444-196c-42e9-94ef-18443b58310e b39b42e27f8646acad1303711f1dc8b8 e4ab1a6192b9486da698efa311086c53 - - default default] Unable to create trust: no such option collect_timing in group [keystone_authtoken] Use the existing user token. 2024-11-07 07:31:19.400 7 ERROR glance.api.v2.image_data [None req-2bd28444-196c-42e9-94ef-18443b58310e b39b42e27f8646acad1303711f1dc8b8 e4ab1a6192b9486da698efa311086c53 - - default default] Failed to upload image data due to internal error: OSError: unable to receive chunked part 2024-11-07 07:31:19.426 7 ERROR glance.common.wsgi [None req-2bd28444-196c-42e9-94ef-18443b58310e b39b42e27f8646acad1303711f1dc8b8 e4ab1a6192b9486da698efa311086c53 - - default default] Caught error: unable to receive chunked part: OSError: unable to receive chunked part 2024-11-07 07:31:19.426 7 ERROR glance.common.wsgi Traceback (most recent call last): 2024-11-07 07:31:19.426 7 ERROR glance.common.wsgi File "/var/lib/openstack/lib/python3.10/site-packages/glance/common/wsgi.py", line 1302, in __call__ 2024-11-07 07:31:19.426 7 ERROR glance.common.wsgi action_result = self.dispatch(self.controller, action, 2024-11-07 07:31:19.426 7 ERROR glance.common.wsgi File "/var/lib/openstack/lib/python3.10/site-packages/glance/common/wsgi.py", line 1345, in dispatch 2024-11-07 07:31:19.426 7 ERROR glance.common.wsgi return method(*args, **kwargs) 2024-11-07 07:31:19.426 7 ERROR glance.common.wsgi File "/var/lib/openstack/lib/python3.10/site-packages/glance/common/utils.py", line 415, in wrapped 2024-11-07 07:31:19.426 7 ERROR glance.common.wsgi return func(self, req, *args, **kwargs) 2024-11-07 07:31:19.426 7 ERROR glance.common.wsgi File "/var/lib/openstack/lib/python3.10/site-packages/glance/api/v2/image_data.py", line 299, in upload 2024-11-07 07:31:19.426 7 ERROR glance.common.wsgi with excutils.save_and_reraise_exception(): 2024-11-07 07:31:19.426 7 ERROR glance.common.wsgi File "/var/lib/openstack/lib/python3.10/site-packages/oslo_utils/excutils.py", line 227, in __exit__ 2024-11-07 07:31:19.426 7 ERROR glance.common.wsgi self.force_reraise() 2024-11-07 07:31:19.426 7 ERROR glance.common.wsgi File "/var/lib/openstack/lib/python3.10/site-packages/oslo_utils/excutils.py", line 200, in force_reraise 2024-11-07 07:31:19.426 7 ERROR glance.common.wsgi raise self.value 2024-11-07 07:31:19.426 7 ERROR glance.common.wsgi File "/var/lib/openstack/lib/python3.10/site-packages/glance/api/v2/image_data.py", line 162, in upload 2024-11-07 07:31:19.426 7 ERROR glance.common.wsgi image.set_data(data, size, backend=backend) 2024-11-07 07:31:19.426 7 ERROR glance.common.wsgi File "/var/lib/openstack/lib/python3.10/site-packages/glance/notifier.py", line 492, in set_data 2024-11-07 07:31:19.426 7 ERROR glance.common.wsgi with excutils.save_and_reraise_exception(): 2024-11-07 07:31:19.426 7 ERROR glance.common.wsgi File "/var/lib/openstack/lib/python3.10/site-packages/oslo_utils/excutils.py", line 227, in __exit__ 2024-11-07 07:31:19.426 7 ERROR glance.common.wsgi self.force_reraise() 2024-11-07 07:31:19.426 7 ERROR glance.common.wsgi File "/var/lib/openstack/lib/python3.10/site-packages/oslo_utils/excutils.py", line 200, in force_reraise 2024-11-07 07:31:19.426 7 ERROR glance.common.wsgi raise self.value 2024-11-07 07:31:19.426 7 ERROR glance.common.wsgi File "/var/lib/openstack/lib/python3.10/site-packages/glance/notifier.py", line 443, in set_data 2024-11-07 07:31:19.426 7 ERROR glance.common.wsgi self.repo.set_data(data, size, backend=backend, 2024-11-07 07:31:19.426 7 ERROR glance.common.wsgi File "/var/lib/openstack/lib/python3.10/site-packages/glance/quota/__init__.py", line 322, in set_data 2024-11-07 07:31:19.426 7 ERROR glance.common.wsgi self.image.set_data(data, size=size, backend=backend, 2024-11-07 07:31:19.426 7 ERROR glance.common.wsgi File "/var/lib/openstack/lib/python3.10/site-packages/glance/location.py", line 596, in set_data 2024-11-07 07:31:19.426 7 ERROR glance.common.wsgi self._upload_to_store(data, verifier, backend, size) 2024-11-07 07:31:19.426 7 ERROR glance.common.wsgi File "/var/lib/openstack/lib/python3.10/site-packages/glance/location.py", line 487, in _upload_to_store 2024-11-07 07:31:19.426 7 ERROR glance.common.wsgi multihash, loc_meta) = self.store_api.add_with_multihash( 2024-11-07 07:31:19.426 7 ERROR glance.common.wsgi File "/var/lib/openstack/lib/python3.10/site-packages/glance_store/multi_backend.py", line 397, in add_with_multihash 2024-11-07 07:31:19.426 7 ERROR glance.common.wsgi return store_add_to_backend_with_multihash( 2024-11-07 07:31:19.426 7 ERROR glance.common.wsgi File "/var/lib/openstack/lib/python3.10/site-packages/glance_store/multi_backend.py", line 479, in store_add_to_backend_with_multihash 2024-11-07 07:31:19.426 7 ERROR glance.common.wsgi (location, size, checksum, multihash, metadata) = store.add( 2024-11-07 07:31:19.426 7 ERROR glance.common.wsgi File "/var/lib/openstack/lib/python3.10/site-packages/glance_store/driver.py", line 294, in add_adapter 2024-11-07 07:31:19.426 7 ERROR glance.common.wsgi metadata_dict) = store_add_fun(*args, **kwargs) 2024-11-07 07:31:19.426 7 ERROR glance.common.wsgi File "/var/lib/openstack/lib/python3.10/site-packages/glance_store/capabilities.py", line 176, in op_checker 2024-11-07 07:31:19.426 7 ERROR glance.common.wsgi return store_op_fun(store, *args, **kwargs) 2024-11-07 07:31:19.426 7 ERROR glance.common.wsgi File "/var/lib/openstack/lib/python3.10/site-packages/glance_store/_drivers/filesystem.py", line 764, in add 2024-11-07 07:31:19.426 7 ERROR glance.common.wsgi raise errors.get(e.errno, e) 2024-11-07 07:31:19.426 7 ERROR glance.common.wsgi File "/var/lib/openstack/lib/python3.10/site-packages/glance_store/_drivers/filesystem.py", line 746, in add 2024-11-07 07:31:19.426 7 ERROR glance.common.wsgi for buf in utils.chunkreadable(image_file, 2024-11-07 07:31:19.426 7 ERROR glance.common.wsgi File "/var/lib/openstack/lib/python3.10/site-packages/glance_store/common/utils.py", line 73, in chunkiter 2024-11-07 07:31:19.426 7 ERROR glance.common.wsgi chunk = fp.read(chunk_size) 2024-11-07 07:31:19.426 7 ERROR glance.common.wsgi File "/var/lib/openstack/lib/python3.10/site-packages/glance/common/utils.py", line 294, in read 2024-11-07 07:31:19.426 7 ERROR glance.common.wsgi result = self.data.read(i) 2024-11-07 07:31:19.426 7 ERROR glance.common.wsgi File "/var/lib/openstack/lib/python3.10/site-packages/glance/common/utils.py", line 121, in readfn 2024-11-07 07:31:19.426 7 ERROR glance.common.wsgi result = fd.read(*args) 2024-11-07 07:31:19.426 7 ERROR glance.common.wsgi File "/var/lib/openstack/lib/python3.10/site-packages/glance/common/format_inspector.py", line 956, in read 2024-11-07 07:31:19.426 7 ERROR glance.common.wsgi chunk = self._source.read(size) 2024-11-07 07:31:19.426 7 ERROR glance.common.wsgi File "/var/lib/openstack/lib/python3.10/site-packages/glance/common/wsgi.py", line 1045, in read 2024-11-07 07:31:19.426 7 ERROR glance.common.wsgi data = uwsgi.chunked_read() 2024-11-07 07:31:19.426 7 ERROR glance.common.wsgi OSError: unable to receive chunked part 2024-11-07 07:31:19.426 7 ERROR glance.common.wsgi Ceph Cluster Status: NAME DATADIRHOSTPATH MONCOUNT AGE PHASE MESSAGE HEALTH EXTERNAL FSID ceph /var/lib/rook 3 82m Ready Cluster created successfully HEALTH_OK 5cf8b9bb-13e1-4c31-b47d-9e7d92c3c05d Ceph osd status: ID CLASS WEIGHT REWEIGHT SIZE RAW USE DATA OMAP META AVAIL %USE VAR PGS STATUS TYPE NAME -1 0.35156 - 360 GiB 3.3 GiB 493 MiB 0 B 2.8 GiB 357 GiB 0.91 1.00 - root default -5 0.11719 - 120 GiB 1.1 GiB 164 MiB 0 B 964 MiB 119 GiB 0.92 1.01 - host instance-lu-1 2 hdd 0.11719 1.00000 120 GiB 1.1 GiB 164 MiB 0 B 964 MiB 119 GiB 0.92 1.01 195 up osd.2 -3 0.11719 - 120 GiB 1.1 GiB 164 MiB 0 B 951 MiB 119 GiB 0.91 1.00 - host instance-lu-2 0 hdd 0.11719 1.00000 120 GiB 1.1 GiB 164 MiB 0 B 951 MiB 119 GiB 0.91 1.00 195 up osd.0 -7 0.11719 - 120 GiB 1.1 GiB 164 MiB 0 B 951 MiB 119 GiB 0.91 1.00 - host instance-lu-3 1 hdd 0.11719 1.00000 120 GiB 1.1 GiB 164 MiB 0 B 951 MiB 119 GiB 0.91 1.00 197 up osd.1 TOTAL 360 GiB 3.3 GiB 493 MiB 0 B 2.8 GiB 357 GiB 0.91 MIN/MAX VAR: 1.00/1.01 STDDEV: 0.01 now i'm able to create Empty Volume using horizon(can't create volume using default cirros image ) and i can start an Instance without volume and mount the empty volume in(Ceph also can detect when i use that volume) is there something i need to set when starting glance? because i'm following the Openstack-helm installation document to install openstack with helm

5 8

[all][tc][ptg] OpenStack Technical Committee Gazpacho PTG Summary
by Goutham Pacha Ravi 07 Nov '25

07 Nov '25

Hello Stackers, The community had a very productive "design summit" at the Project Teams Gathering last week. As you're reading the various summaries posted here, and participating in new initiatives that have rolled out since, I'd like to add a brief summary of the OpenStack Technical Committee's meetings [0] at the PTG. We recorded all of these sessions and have posted the recordings to the TC's YouTube channel [1]. Alongside this summary, I'd recommend reading the Eventlet Removal Goal updates and discussion from the session that Hervé Beraud (hberaud) hosted [2]. Remember, Etherpads are true to their name—you can lose them :D So we made a handy reference to the PTG Etherpads on the wiki [3]. Community Leaders' Forum ====================== We discussed active Community Goals [4], and took questions regarding the status from various project maintainers. As it stands, the FIPS compliance goal may no longer fit the criteria for community goals. It's been challenging due to the lack of a stable OS to test FIPS compliance in the CI. The community may need to explore CentOS Stream alternatives such as Rocky Linux 10 and Alma Linux 10. We need someone to pick up the work and replace existing test jobs. Secure RBAC has got an active Goal Champion; however, work has slowed down in several project teams. We're hoping to make another push through the Gazpacho cycle. We agreed that the current cross project liaisons information (on a wiki) is severely outdated and needs to be migrated to the openstack/governance repository, a centralized, programmatic location, to avoid duplication and ensure accuracy. We also discussed the OpenInfra AI contribution policy. Some project teams have recently seen an uptick in AI-assisted contributions, but there has been some confusion, and potential stigmatization of such contributions. We identified a need for clarity on how to apply the AI policy, specifically regarding using AI-generated code and verifying copyrights. We could use some documentation and guidelines for contributors and reviewers. Action Items: - Goutham (gouthamr) will move the FIPS goal from "selected" to "proposed" and start a separate ML thread. Project teams can remove any failing FIPS jobs when this change merges. - Tony Breeds (tonyb) will enhance the project schema in the governance repository to support adding cross-project liaisons. - (needs volunteers) The FIPS goal needs rework, especially around testing, and any objective refinements. - (needs volunteers) Clarifications and instructions pertaining to AI Contributions in the Project Team Guide. Testing and Runtimes ================= We discussed testing matrix updates for MariaDB/MySQL versions and Linux distributions. The goal is to drop older, unmaintained versions and move to modern platforms (like newer Python versions, CentOS Stream, AlmaLinux, and Rocky Linux) to ensure compatibility and support. AlmaLinux images are now available, but no projects are currently testing with them. Kolla and OpenStack-Ansible project teams are currently interested. The biggest advantage to project teams with this would be that the wide gamut of CI providers are compatible with this Red Hat-like distribution because of its support for x86_64v2 and x86_64v3 CPU architectures (as opposed to CentOS Stream or Rocky Linux). The CentOS Stream community has offered to run a third-party CI to test CentOS Stream with OpenStack, and the team noted a good meeting between maintainers in both communities at the OpenInfra Summit in Paris that Amy Marrich (spotz) facilitated. A precursor to this discussion was the concern that the latest LTS versions of MariaDB/MySQL have changed the default behavior with respect to character sets and collations, and several OpenStack services are non-compliant with these changes. We agreed that OpenStack services need to specify the character set on tables explicitly, and so creating a community goal to mandate the use of a specific character set (and to handle character set migrations) was seen as a good path forward. We briefly discussed OpenStack Special Interest Groups. We noted that we could use fresh updates to the SIGs website, including refreshing the SIG Chairs of several SIGs. There was a suggestion that, during this exercise, we could suggest merging some SIGs, such as the Scientific SIG and other operationally related SIGs, under a more general OpenStack operators umbrella. Action Items: - Dmitriy Rabotyagov (noonedeadpunk) will propose a community goal for project teams to support character set changes in newer LTS releases of MariaDB/MySQL. - tonyb will refresh the data for all the SIGs. - gouthamr will merge the governance and governance-sigs repositories for ease of management. University Partnerships and Collaborations ================================== Kendall Nelson (diablo_rojo) would like us to maintain an ongoing list of projects and mentors for OpenStack's storied university interns. This would alleviate bottlenecks and increase student engagement in OpenStack. There's now an Etherpad for this purpose [5]. If you'd like to mentor, please do sign up. We also entertained the idea of combining efforts with the First Contact SIG, as it has not been active in a while, to create a running list of mentors and participants for various onboarding events and activities throughout the community. Action Items: - Community members sign up and propose projects [5] - Revive First Contact SIG by collaborating with the University Partnership Projects. Post-Quantum Cryptography ======================= We discussed the potential breaking of traditional asymmetric cryptography by quantum computers around 2030. JP Jung (JP) joined us to detail that there are 17 cryptographic modules in OpenStack, and the goal is to understand the problem in each project, catalog the cryptographic algorithms used, and make the entire chain well-known to achieve quantum safety. A significant concern was that OpenStack has security threats today, and the energy should be directed towards securing it for current use cases as well, not just focusing on potential future threats like quantum computing. It was noted that the Python ecosystem has minimal support for post-quantum cryptography, and Python's cryptography project has not committed to a timeline for adding support, so building a foundation with cryptography or alternative libraries might be necessary before focusing on OpenStack. JP proposed a document for the community to review [6]. Much of it probably has to be less verbose and focus on specific gaps/changes. JP's willing to be a champion of the effort to secure OpenStack in a post-quantum world. He'd like project teams to audit the use of encryption algorithms, key exchange libraries/mechanisms in their deliverables. The Security SIG is a good venue to continue this discussion, and, if necessary, a sub-team or a separate pop-up team can be formed as well. Action Items: - JP will fix up the current analysis [6] to make it specific, and highlight actionable problems. OpenStack Universe a.k.a Affiliated Projects ================================== Artem Goncherov (gtema) wanted to address the issue of signaling to users that certain tools work well with OpenStack, even if they are not official OpenStack projects. The idea is to create a connection between OpenStack and these affiliated projects, giving them recognition and a voice, and potentially providing some protection from competing projects. Thierry Carrez (ttx) suggested that the OpenInfra Universe [7] is an existing platform that lists projects in a similar category, with criteria including OSI-recognized licenses and integration with Open Infra projects. We brainstormed how to evolve the current project intake form to better represent affiliated projects, with a potential meeting to include OpenInfra Marketing folks and explore options. Action Items: - ttx will set up a meeting with interested parties to improve the OpenInfra Universe, and will share updates in a future OpenStack TC meeting. Bridging the gap between community and contributing orgs ============================================= Ildiko Vancsa (ildikov), Jeremy Stanley (fungi) and Clark Boylan (clarkb) provided an update on the effort to bridge the gap between the community and contributing organizations. There are two surveys that are currently open to contributors [8] and maintainers [9]. These surveys focus on the Flamingo release cycle and will end on November 16th, 2025. (Please take them!) Once these surveys end, we're expecting them to inform us of where things are going well and where they are not, and to measure the effectiveness of changes we've slowly been making across the community, with the ultimate goal of improving the contributor experience. There is a perception that getting a feature into OpenStack requires a personal relationship with a maintainer, which can be a barrier to entry for new contributors. The complexity of OpenStack's CI and software can also be a significant technical element that makes it difficult for external contributors to get started. Collectively, we're having trouble finding new core maintainers and building knowledge in parts of our code base to sustain them. Extending trust and lowering barriers to entry can help address these issues, and projects should consider reevaluating their processes to make it easier for new contributors to get involved. It was also highlighted that #openstack and #openstack-dev IRC channels on OFTC have become less active over time. We explored the idea of revitalizing these channels as preferred venues for cross-project discussions, and having maintainers parked there to engage with folks that aren't familiar with project-specific channels or have cross-project concerns. Action Items: - Please take the contributor [8] and maintainer [9] surveys for the 2025.2 "Flamingo" release. - (ildikov/fungi) Analyze survey results when surveys close and meet with project teams and the OpenStack TC to discuss them. Project Cascade ============= Professor Corey Leong (profcorey) introduced the Cascade project, an open-source unified communications project. He asked us about the steps to make it an official OpenStack project, including potential voting and governance requirements. The project aims to integrate unified communications services, such as voice, phone, and video using open-source projects, including OpenStack components. It'd allow OpenStack users to download and install the service on their machines. Participants drew a similarity to Trove in that Cascade would provide a managed service to OpenStack users akin to Trove providing database-as-a-service. We opined that the project is still in the early stages, and the team is researching how to integrate with OpenStack components, including identifying dependencies and interactions between services. In this stage, all of the community's infrastructure: hosting on OpenDev, publishing on wiki.openstack.org, using official IRC channels on OFTC, Meetpad, Gerrit, and Zuul, are available to Project Cascade's maintainers. We tried to understand the benefits of switching to the OpenStack namespace, i.e., bringing the project under OpenStack governance and what it would provide that is not currently available. We hope to continue this discussion in a future TC meeting or on the openstack-discuss mailing list. Action Items: - tonyb is working on fixing OpenID auth issues with wiki.openstack.org and will coordinate with profcorey on problems with other maintainer infrastructure. Now that we have that out of the way, we can focus on some other important things [10]. Again, thank you very much for participating and for the great discussions over the week! Sincerely, Goutham Pacha Ravi (gouthamr) Chair, OpenStack Technical Committee [0] OpenStack TC PTG Etherpad: https://etherpad.opendev.org/p/r.5dfdc57d7bc31731ccf9d51cb80de6c5 [1] OpenStack TC Gazpacho PTG playlist: https://www.youtube.com/playlist?list=PLhwOhbQKWT7WkK5VGgipjt4XQQlgLLci9 [2] Hervé's summary of eventlet-removal: https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack… [3] "Gazpacho" Oct 2025 PTG Etherpads: https://wiki.openstack.org/wiki/PTG/Oct2025PTG/Etherpads [4] OpenStack Wide Goals: https://governance.openstack.org/tc/goals/ [5] University Mentors Sign Up: https://etherpad.opendev.org/p/UPP-Projects%26Mentors [6] Post Quantum OpenStack: https://wiki.openstack.org/wiki/Post_quantum_openstack [7] OpenInfra Universe: https://openinfra.org/universe [8] Flamingo Contributor Survey: https://openinfrafoundation.formstack.com/forms/openstack_contributor_exper… [9] Flamingo Maintainer Survey: https://openinfrafoundation.formstack.com/forms/openstack_maintainer_experi… [10] https://cooking.nytimes.com/recipes/1017577-best-gazpacho

1 0

[i18n] Summary of 2026.1 Gazpacho PTG Discussions
by Seongsoo Cho 07 Nov '25

07 Nov '25

Hello all, I would like to share with you a summary of the recent discussions held during the 2026.1 Gazpacho virtual PTG regarding the i18n SIG. We had several productive sessions focused on our two main goals for the upcoming cycles: the Weblate Migration, and a forward-looking discussion on AI Translation. Special thanks to the OpenDev Infra Team for the infrastructure support, the OpenSource Contribution Academy mentees in Korea who worked on the Weblate migration, and the KNU students who brought great energy and ideas to our AI discussion. Please refer to the full details from our Etherpad: https://etherpad.opendev.org/p/oct2025-ptg-i18n 1. Weblate Migration Status & Challenges A significant portion of our PTG was dedicated to the ongoing migration from Zanata to Weblate. - Migration Status: DaGyeong Kim presented the current status. 15 dashboard projects were initially migrated, but we identified issues that require a retry. A detailed status page is tracking all projects [1]. - Tooling Development: We are actively developing and refining automation scripts to manage the migration, including language creation/deletion and handling plural forms (patches [2], [3]). This work is being tracked in a blueprint [4]. - Key Challenge - Language Definitions: We are addressing mismatches between Zanata's language codes (e.g., ko_KR) and Weblate's CLDR standards (e.g., ko), especially concerning plural form definitions. - Verification of Migration Completion: It was discussed that a clear method needs to be defined to verify whether all translated PO files in Zanata have been successfully migrated to Weblate. In subsequent discussions, it was agreed to establish specific criteria for accurate verification and to proceed with the work based on those criteria. 2. Zuul Integration & Infrastructure The second major topic was integrating our new Weblate instance with the OpenDev (Zuul) CI/CD pipeline. - Core Patches: We reviewed the main patches for openstack-zuul-jobs [5] and project-config [6] that will enable Weblate to propose translation updates. - New Zuul Job Testing Strategy: It was discussed to create a completely new job to minimize the impact and to apply it to specific projects first, gradually expanding its scope over time. 3. AI Translation PoC We held an exciting session with students from Kyungpook National University (KNU) to discuss a Proof-of-Concept (PoC) for using AI in our translation workflow. - Goals: The discussion focused on two potential tools: - An automated, CPU-based LLM tool (e.g., using Ollama) to catch new strings from merged patches and provide initial translations. - A local AI-assisted tool for translators to help with the initial translation of large .po files. - Next Steps: We are exploring different instance flavors for performance and comparing the pros/cons of self-hosting a model versus using external APIs (similar to the Firefox translation model). 4. I18n Repository Packaging We are working to package the openstack i18n repository [7] and publish an updated package to PyPI. This initiative aims to enhance productivity by independently managing the tools related to i18n. Best Regards Seongsoo Cho [1] https://wiki.openstack.org/wiki/I18nTeam/Migration-to-weblate#List_of_proje… [2] https://review.opendev.org/c/openstack/i18n/+/961371 [3] https://review.opendev.org/c/openstack/i18n/+/963758 [4] https://blueprints.launchpad.net/openstack-i18n/+spec/weblate-migration [5] https://review.opendev.org/c/openstack/openstack-zuul-jobs/+/921878 [6] https://review.opendev.org/c/openstack/project-config/+/961499 [7] https://review.opendev.org/c/openstack/i18n/+/955037

3 2

[manila] 2026.1 Gazpacho PTG summary
by Carlos Silva 07 Nov '25

07 Nov '25

Hello, Zorillas and interested stackers. Here's a summary of all the discussions, decisions, action items and plans we came up with during last week's PTG. All of the recordings are available in this playlist [10] from the OpenStack Manila Youtube channel. In case you missed something and would like to get back to the discussions, please refer to it. Flamingo Retrospective ================== We discussed what went well and what needs some attention in the upcoming cycles. - Bugsquash events and collaborative review sessions are having a positive impact on bugs being closed and features being reviewed faster. - The mid cycle helped with the reviews of the changes prior to the feature freeze. - We had several interns working on Manila UI, OpenAPI patches and fixing other known issues in Manila, providing good opportunities for community engagement. - We had enhancements on the review bandwidth but we should keep looking on adding more core reviewers to Manila and help share the load on reviews. We didn't manage to cover all topics, so the retrospective will continue in the next Manila upstream weekly meeting, November 13th. All Things CephFS: Status and Gazpacho Plans ===================================== Status updates ------------------------ - Allocated Capacity GiB fixes and thin provisioning improvements are being backported to older releases. - fs_name metadata is now also used in Manila CSI [2] - Patches to introduce CI testing for CephFS manage/unmanage operations will be included in the Gazpacho cycle. Plans for 2026.1 Gazpacho ------------------------------------ - We started testing with Ceph Tentacle release candidate images in the devstack jobs and will merge these jobs once the official Ceph Tentacle release is out. *QoS:* NFS Ganesha v7 supports QoS, i.e., throughput throttling (iops and bandwidth) Manila team intends to start the CephFS NFS driver implementation during this cycle. The implementation is expected to support the new proposed QoS types alongside driver-scoped share type extra specs. *Share encryption (BYOK):* NFS-Ganesha and Ceph communities are working on Bring-Your-Own-Key subvolume encryption. The team will work on a Proof of Concept (PoC) to extend the existing BYOK Encryption feature in Manila to support shares encryption with CephFS. *OVN extension targeting NFS-Ganesha* Discussion is ongoing with the Neutron project team for adding an extension to the OVN agent [3], which aims to improve usability and security in a cloud that relies on NFS-Ganesha to provide RWX storage volumes to end-user workloads. [NetApp] Sync snapmirror support and Async snapmirror enhancements ======================================================= NetApp is adding support for zero RPO (i.e., synchonous mirroring) with Share Replication - a feature that's been supported by this driver since the Mitaka release. Doing this will involve some more tenant-visible directives. The Manila team considered it as a good enhancement, but suggested implementing share replicas metadata as the vehicle for this change, as this will make it more extensible and reusable in the future. The NetApp team agreed with this approach and will work on implementing share replicas metadata in the Gazpacho cycle. Graduating Migration and Backup APIs ============================== Share backup APIs -------------------------- The Share Backup APIs are mostly feature complete. We're missing a way to force backup deletion and the ability to set backup quota via the CLI and UI. Some improvements are planned for the Share Backup driver abstraction as well. We are also evaluating the possibility of adding testing with CERN's CBACK utility and Backup driver in the CI, and Zac is working on further enhancements for targeted restores. Share migration APIs status ------------------------------------- The share migration APIs have been stable for a while and well tested. We believe that this API is ready to be graduated and we need a contributor to help drive this to completion. Share Encryption follow up ==================== The Manila team discussed the known issues and gaps noted while reviewing and merging this feature in the flamingo cycle: - Inability to unmanage/manage share servers with encrypted shares: the NetApp team will investigate how to implement the changes to the manage share servers workflow. - We agreed that this should also follow steps similar to the creation workflow, as, for example, checking if the barbican key exists, if the user can manipulate it, and if it matches the one from the share server. - Inability to migrate share servers and setup share replication: the NetApp team will look into the required next steps. NetApp - NAE (NetApp Aggregate Encryption) Support ========================================== NetApp is planning to add support for encrypted pools (aggregates) to Manila when DHSS=True is in use [4]. It will allow customers to encrypt the shares (volumes) data by assigning the encryption key to aggregate level. The Manila team is okay with this proposal and the NetApp team will start this implementation in the Gazpacho release cycle. Adding new/failure notification ======================= We currently have notifications for share operations (create, shrink, delete). eunkyung, a contributor from Samsung would like to add notifications for other operations in Manila (creating snapshots, reverting to snapshots and others). The team agreed that this is a great addition, as we started with notifications for shares but didn't have the cycles for adding notifications to other resources. This change will be proposed to Manila and the Manila team will share feedback. Add mount_point_name option to managing share ====================================== It is currently possible to define a custom mount point name to a share export location, but while managing a share, it is not possible. We discussed the possibility of extending this feature to the manage workflow and agreed that this is will be a great improvement for the operators. This feature will be proposed during the Gazpacho cycle and the Manila team will review. QoS enhancements =============== Kiran shared a proposal for introducing QoS types in Manila, with the possibility of having multiple QoS types being linked to a share type. The QoS types will be added to the share servers and shares created. The team agrees that this is a nice addition, and we asked more details in the specification [5] seeking clarifications on spec conflicts and to elaborate on the need to tie the QoS types to the share type itself, instead of using an approach to tie them directly to shares or share servers. Eventlet Removal ============= The manila team is actively working on removing eventlet. We used this topic to talk about the progress from the team, share our plans, roadmap and discuss an issue shared by Eric from the Cinder team, where sqlalchemy objects shared by multiple threads were affected when dropping eventlet from the cinder-volume service. damani joined us for the discussion and has started on changes that are going to address this behavior [6][7]. The Manila team intends to support running all manila components without eventlet by the end of the Gazpacho release. Dropping the v1 API =============== The Manila v1 API was deprecated ~10 years ago and we intend to remove it during the Gazpacho Cycle. Removing it will clean up our code and make enhancements such as the JSON Schema Validation work easier. This work will help us with the OpenAPI schema and documenatation enhancements that we've been slowly closing the gap on for the past few releases. AI: carloss will send an email to the mailing list announcing the removal. JSON Schema Validation =================== We shared the current status of the JSON Schema validation changes in Manila and also talked about the lack of reviews in the open changes. We decided to split changes up into smaller chunks, making it more friendly to new contributors, and to reviewers. AI: carloss will organize a Review Jam to help making progress, as well as unify the tracking of the current issues being worked on in a Taiga board [8]. Manila client removal + merging manilaclient's OSC functionality into OSC ======================================================== The Manila CLI utility was deprecated several release cycles ago and we intend to remove it in the Gazpacho cycle. We also discussed moving Manila's OSC functionality from python-manilaclient into openstackclient itself. Doing this will reduce the burden to discover and import command modules at runtime, significantly improving performance of OSC. We discussed the work that would be needed and how it would affect the release process. NetApp REST/ZAPI situation ====================== Retirement of NetApp's ONTAPI is currently on hold [9]. Many OpenStack users are still heavily relying on ZAPI because of how the NetApp drivers in Cinder and Manila integrate with the product. All new ONTAP features will be added only to REST, with no fallback approach to ZAPI. So, the drivers in OpenStack have started seeing implementation changes over several releases to support NetApp's REST API where available. The NetApp team is also putting efforts into identifying the gaps between REST and ZAPI in Manila. As for CI Testing: Stabilizing CI runs with REST is a priority for the NetApp team, with an engineer actively working on the necessary fixes. Improvements for managing shares/snapshots =================================== The proposal is to update the snapshot's created_at field to reflect the creating time on the storage backend during the manage operation, rather than the time recorded by Manila. We agreed with the proposal but also think this should be applied for the shares. A blueprint will be registered and inyonghong will work on the fix. Dell's PowerScale driver roadmap ========================== We heard requests for a couple of features in the Dell PowerScale drivers: - manage/unmanage for shares and snapshots - revert to snashot - custom mount point names - QoS. We noted that the revert to snapshot feature is already being worked on by the Dell team and the Manila team will review the changes and target them for the gazpacho cycle. [1] https://etherpad.opendev.org/p/gazpacho-ptg-manila [2] https://github.com/kubernetes/cloud-provider-openstack/pull/2994 [3] https://review.opendev.org/c/openstack/neutron-specs/+/936063/3/specs/2025.… [4] https://etherpad.opendev.org/p/nteapp_nae_support [5] https://review.opendev.org/c/openstack/manila-specs/+/962706 [6] https://review.opendev.org/c/openstack/oslo.service/+/963742 [7] https://review.opendev.org/c/openstack/oslo.service/+/965208 [8] https://tree.taiga.io/project/gouthampacha-manila-jsonschema-openapi/kanban [9] https://kb.netapp.com/on-prem/ontap/DM/REST-API/REST_API_KBs/Deferral_of_ON… [10] https://www.youtube.com/watch?v=3O3ByYU6gHc&list=PLnpzT0InFrqAf4kRsXDoVpv0V… Lots of positives to take from this PTG and definitely a productive cycle ahead. Thank you for your participation! Regards, carloss

1 0