November 2025 - openstack-discuss

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

[all][dev][ops][tc] Bridging the gap between community and contributing orgs
by Jeremy Stanley 11 Nov '25

11 Nov '25

The tl;dr on this is that I'm opening a broad community discussion on how we can, collectively through improved communication, better bring together our established contributors with casual and prospective contributors who struggle to find successful patterns of contribution, so that we might all support each other in order to benefit OpenStack as a whole. Read on for details... OpenStack's TC has requested that foundation staff, when in conversation with representatives of member organizations, encourage participation in the project and collect feedback on any related challenges those organizations encounter in their attempts to do so. In order to better understand the feedback and brainstorm achievable recommendations for the broader community[*], Community Managers on the foundation staff started to work with a small focus group of established contributors with a solid understanding of what successful patterns of contribution look like. It also came to light that established contributors experience many of the same sorts of challenges, even more so if they don't have the luxury of focusing full-time upstream, and so success often comes down to knowing how to effectively navigate those challenges. The community's goal with this exercise is to improve everyone's experience, and your help is needed to do that! The most common themes reported by those struggling to contribute are not related to tooling or workflow confusion, but instead seem to come down to basic communication challenges. Ideas so far to address these gaps include: * Review bandwidth - Ensure contributors and companies understand the importance and benefits of code review - Incentivize and credit meaningful "+1" reviews more - Understand that the volume of changes and limited reviewer bandwidth often means proposals aren't reviewed quickly (or at all), and their proponents may need some additional tenacity and engagement with the team to get their work noticed - Utilize "review dashboards" as a way to find stale changes which have fallen through the cracks * Review strategy and etiquette - Be clear about the meaning of votes on changes, especially negative ones, and set explicit timelines for things like "procedural -2" or WIP blocks when their approval needs to be delayed - Focus on comments and requests that affect whether or not the change can be merged after the fixes are submitted, rather than requesting trivial adjustments to an unsuitable change which has more fundamental problems - Reciprocate with reviews of changes from new reviewers you see leaving insubstantial reviews, demonstrating to them what deeper and more meaningful reviewing looks like * Mentoring newcomers - Established contributors with sufficient bandwidth can help mentoring newcomers, potential core reviewers and new leaders - Mentoring can happen as part of internship programs as well as by helping newcomers determined to become active contributors; both ways should be embraced and utilized What challenges are you facing? And, how would you improve them? Two weeks from now, we'll have a forum session at the OpenInfra Summit Asia in Suwon[**] where our community can refine these possible approaches and integrate others, as well as bring attention to them and promote their application. I've also proposed a similar forum session for OpenInfra Days North America in Indianapolis a month after that, where we can hopefully continue this conversation. The goal for this multi-stage effort is to improve the contribution experience for established participants, casual contributors and newcomers alike. While it's easy to jump to blaming in these situations, it will be far more productive if we can focus on the challenges and experiences that we would each like to remove or improve for ourselves and others in our community. As we find ways together to improve our efficiency, we can reduce the load on all contributors and lower the barriers for people to join and participate. [*] https://etherpad.opendev.org/p/r.2205024e55689bccb82c20c960853cb5 [**] https://2024.openinfraasia.org/a/schedule#view=calendar&title=Bridging%20th… -- Jeremy Stanley

2 14

[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 11 Nov '25

11 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