April 2026 - openstack-discuss - lists.openstack.org

[horizon][PTG] 2026.2 Hibiscus PTG summary
by Tatiana Ovchinnikova 27 Apr '26

27 Apr '26

Hello everyone, A big thank you to everyone who participated in the OpenStack Horizon Hibiscus PTG, whether you organized sessions, presented, or joined the discussions, you made the event a great success! You can find the full list of sessions and topics on our Etherpad: https://etherpad.opendev.org/p/apr2026-ptg-horizon Here is a summary of the key topics: # Gazpacho Retrospective The team reviewed the successful migration of several tables and forms to Python, tests improvements and updates. # Requirements & CI Stability Discussion with Michał Nasiadka focused on creating dedicated jobs to catch breaking dependency updates before they merge. # Hibiscus Cycle Planning The team prioritized continuing the deangularization work, upgrading to Django 5.2, implementing TOTP MFA enrollment, and the OpenStackSDK transition. # OpenInfra User Group Kenya Abby Nduta presented on local community growth and the coordination of UbuCon Kenya 2026. # Review Cycle Optimization The team discussed improving review processes to reduce contributor friction and speed up patch approvals. # Test Stability Update Maintenance reports confirmed that the new pytest-based integration and UI suites are now highly stable compared to legacy tests. # Nova Cross-Project Session Developers coordinated a resource-by-resource migration from novaclient to OpenStackSDK, starting with Flavors and Availability Zones. # De-Angularization Progress The session established a new reusable "Chevron" base class pattern to accelerate the replacement of legacy AngularJS tables with Django versions. With kind regards, Tatiana

1 0

[ops][largescale-sig][scientific-sig][publiccloud-sig][ptl][tc] Ops Sessions at the PTG
by Ildiko Vancsa 27 Apr '26

27 Apr '26

Hi OpenStack community, I'm reaching out to you with a friendly reminder that the next OpenStack Ops Radio Hour[1] is scheduled to happen on __April 24th, 2026 at 1300UTC,__ which is next Friday! The call series is a casual setting for operators, engineers, and contributors to come together, share knowledge, and collaborate on the complexities of managing and deploying OpenStack environments. The main topic the group identified for the upcoming call is OpenStack Observability practices! If you have any experience with observability and especially implementing it in OpenStack, or would like to find out how others might’ve dine it, please make sure to join the call! If you have further topics you would like to dive into during the call, please add them to this etherpad: https://etherpad.opendev.org/p/openstack_ops_radiohour Additional reminders: - This Ops Radio Hour session is part of the PTG[2], you can find it on the event schedule[3] with the ‘os-ops’ label - There will be a joint session with the OpenStack TC named __TC/Operators Hour__ scheduled for __Monday (April 20) at 1700 UTC__ + Look for the ‘os-tc’ label on the PTG schedule to join + Learn more about the details here: https://lists.openstack.org/archives/list/openstack-discuss@lists.openstack… - Hop into the OpenStack Ops Matrix room to chat between calls: https://matrix.to/#/#openstack-ops:opendev.org - Look out for other Ops-focused sessions at project team slots on their etherpads: https://ptg.opendev.org/etherpads.html See you on the Ops sessions at the PTG next week! Bets Regards, Ildikó [1] https://wiki.openstack.org/wiki/Operations/Meetups [2] https://openinfra.org/ptg/ [3] https://ptg.opendev.org/ptg.html

1 1

[Glance] Summary of 2026.2 Hibiscus PTG discussions
by Cyril Roelandt 27 Apr '26

27 Apr '26

Hello, Glance had its PTG last week. Here is a summary of what was discussed. # Eventlet removal We made some progress during the G cycle. The glanceclient no longer depends on eventlet. The glance_store library depends on eventlet through oslo.rootwrap (only when using Cinder) so we must find a way to fix this. Glance itself has been running without eventlet for a while, but the code required to run it with eventlet is still there, and we aim to remove it during this cycle. # Glance as defender We discussed about the role of Glance as the first line of defense in OpenStack, and how to improve inspection of images when they're added to Glance. # Image encryption Markus Hentsch joined us to discuss Nova-specific issues with image encryption in Glance. # Parallel image import Currently, when importing an image into multiple stores, imports are done sequentially. We will parallelize the process. # s3 credentials: remove secrets from the database We have been storing S3 credentials in the image locations for images in S3. We will stop doing that to improve security. # Image decompression: support for Zip and LHA We decided to keep both Zip and LHA support for image decompression, even though support is incomplete. They will however be considered "second-class citizens" and gzip will be recommended. # Volume backup base image During this cycle, we will need to meet up with Cinder and Nova to discuss a new feature to enable multi-volume VMs to be captured as an image and restored. # Generate temp URL for images We were informed that Ironic might benefit from a new feature that would allow users to generate temporary URLs for images. We still need to discuss this to figure out whether this is something we want to implement. Thanks to everyone who joined the PTG, and happy hacking for this cycle! On behalf of the Glance team, Cyril Roelandt

1 0

[tc][all] OpenStack Technical Committee Weekly Meeting Agenda (2026.2/R-22)
by Goutham Pacha Ravi 27 Apr '26

27 Apr '26

Hello Stackers, After the action-filled OpenInfra PTG week, The OpenStack Technical Committee will resume its regular meeting schedule this week. The next weekly IRC meeting is scheduled to take place on Tuesday, April 28 2026, at 1700 UTC. Please find the meeting agenda and details for joining the meeting on the meeting wiki [1]. On behalf of the OpenStack TC, Goutham Pacha Ravi (gouthamr) OpenStack TC Chair [1] TC Meeting Agenda, 2026-04-28: https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Next_Meeting

1 0

[tc][ptg] 2026.2 "Hibiscus" Technical Committee PTG Summary
by Goutham Pacha Ravi 27 Apr '26

27 Apr '26

Hello Stackers, Here's a summary of the Technical Committee's sessions from the 2026.2 "Hibiscus" Virtual PTG. We met on 20th April, Monday (1600-1800 UTC) and 24th April, Friday (1500-1800 UTC). We took notes on etherpad [1] and posted audio/video recordings to the TC's Youtube Channel [2]. Monday, April 20 2026 ---------------------- Community Leaders' Forum ~~~~~~~~~~~~~~~~~~~~~~~~ The Community Leaders' Forum covered four main topics. diablo_rojo (Kendall Nelson) gave an update on the University Partnership Program, and sought community mentors [3]. Carnegie Mellon University is running an 11-week summer program starting in May with 40 hrs/week commitment from students, and project proposals are due by May 5 on the UPP etherpad [3]. On community goals, gmaan (Ghanshyam Maan) reported that SRBAC is reaching saturation and he plans to remove the temporary "enforce_scope" configuration option from oslo.policy this cycle. This will simplify testing across all projects. fungi (Jeremy Stanley) raised a security concern that inconsistent SRBAC implementations are generating private vulnerability reports where users discover unexpected role behavior across services. We briefly touched on potential new goals around MariaDB collations, Python 3.14 testing, and LLM documentation. I presented the Launchpad hygiene audit [4] showing community bug trackers still owned by individuals rather than openstack-admins, and confirmed that the bulk transfer request had been filed and resolved. On the security front, fungi gave an update on VMT workload: we had published 2 OSSAs in all of 2025 and have already published 8 this year, driven partly by LLM-discovered vulnerabilities. The room discussed how to manage this increasing load without discouraging disclosure, and the general feeling was to move low-confidence reports to public faster while keeping the ability to triage first. Operators' Forum ~~~~~~~~~~~~~~~~ mihalis68 (Chris Morgan) from Bloomberg provided context on the Ops Radio Hour, a monthly virtual meetup he started after in-person operator meetups died post-pandemic. Sessions have covered RabbitMQ, HA, OVN migration, and live migration performance, and they are seeing new operators show up driven by digital sovereignty and VMware migration. The biggest structural problem is community fragmentation: operators aren't concentrated on any single platform, and many are not on openstack-discuss or OFTC/IRC. We discussed the health of operator-facing SIGs and found that the Large Scale SIG is open to folding into the Ops Radio Hour, the "osops" repo is dormant, and the Public Cloud and Scientific SIGs prefer to stay independent at the moment. We highlighted the gap between where developers are and where production clusters are. Operators are asking questions today that developers answered years ago, and the context from those transitions has largely evaporated. This was the constant concern that operators are running really old versions of OpenStack and the community has moved on. mihalis68 noted that Bloomberg only recently decommissioned their use of nova-network. The room agreed we need better discoverability for operator resources (recordings, SIGs, mailing list, wiki) and mihalis68 volunteered to update the OpenStack wiki operators page [5]. On direct feedback, Bloomberg reported that contributing under their own name rather than anonymously has improved engagement with project teams, and that the main barrier to operator participation in the community is simply not knowing where to show up. Friday, April 24 2026 --------------------- User Survey ~~~~~~~~~~~ aprice (Allison Price) presented a proposal to streamline the OpenStack User Survey, which has been running annually for about 13 years. The survey has received feedback that it's too long to fill out. Despite this, participation has been growing year-over-year, averaging around 300 respondents. slaweq (Slawek Kaplonski) offered to update the outdated Neutron driver questions, and TheJulia (Julia Kreger) noted that cross-service review of survey questions would catch blind spots (e.g., Ironic-maintained Neutron plugins). I proposed scrapping all current TC and project-specific questions and rebuilding from scratch. The TC stopped publishing its own analysis of survey results after 2024 because the data wasn't producing useful insights. Jay Faulkner (JayF) raised a structural problem: in larger organizations, getting permission to share deployment details is an ordeal, leading to either zero or several duplicated responses per company. An actionable outcome was JayF's suggestion to split the survey into two instruments: an anonymous individual-feedback survey (answered with personal hat, bucketed by role) and a separate deployment-data survey (architecture and scale, potentially through exec-to-exec channels). gibi (Balazs Gibizer) supported this, noting that aggregate core counts serve the Foundation's and the community's marketing but aren't useful to project maintainers who want to identify pain points. aprice agreed the split is feasible and would address several of these concerns at once. slaweq also flagged that the analytics page at openstack.org/analytics is currently hard to parse. A working group will be formed to redesign the survey before the August 2026 reopening, with aprice posting a call for volunteers on the openstack-discuss mailing list. AI Contribution Guidelines ~~~~~~~~~~~~~~~~~~~~~~~~~~ This was the most heavily attended TC session of the week, with enough people to crash MeetPad during the group photo. xek (Grzegorz Grasza) opened by noting that adjacent open source projects (Kubernetes, Linux Foundation, QEMU, Python) have published AI policies, but OpenStack's contributor guide doesn't reference the existing OIF AI policy. We agreed early on that the human who submits a patch is fully responsible for it, regardless of what tools were used. JayF connected this to the DCO, arguing that the moment of legal certification is the git-review push to Gerrit, and that fully automated end-to-end submissions are not permitted. sbauza (Sylvain Bauza) shared his experience using LLMs for Nova code review assistance. He curates LLM output personally before posting comments, but stressed we're "months away, if not years away" from trusting LLMs for either code generation or code review. On AI-assisted code review, the room seemed to converge on the point that there is no path to trusting LLMs with +2 or +W in the near or medium term. gibi argued that AI review comments posted under a core reviewer's name create a trust problem: "normal contributors are less likely to push against a questionable code review comment if it is coming from a core reviewer than from an LLM agent." croelandt (Cyril Roelandt) put it more bluntly: "I find it disrespectful to pretend the output of an LLM/bot was made by a human." The agreement seemed to be that automated AI reviewers should use clearly labeled non-human accounts. sean-k-mooney presented results from an 8-month experiment doing this on the Watcher project: running an AI review bot as a third-party CI with a separate bot account. It can catch bugs that diff-only review misses, but only after significant tuning and with his personal oversight of every comment. gtema (Artem Goncharov) raised a security concern: project coresec members must not use remote AI services with embargoed vulnerability information, and agentic workflows can make accidental disclosures easy. VMT policy needs revision to call this out. clarkb (Clark Boylan) flagged OpenDev infrastructure load. He said that agents should point at local context caches (local mbox for mailing lists, cached git repos) rather than fetching entire archives from OpenDev servers. JayF pointed out that a nontrivial part of the open source community finds CLAUDE.md or AGENTS.md in a repo repulsive. A lot of OpenStack's users are infrastructure operators who share that sentiment, and baking AI too deeply into shared tooling could wall off potential contributors. The room also discussed MCP servers for OpenStack: TheJulia opined that letting end users interact with OpenStack through LLMs with proper guardrails was valuable and might pay off better dividends than automating the code development process. We discussed a policy-layer MCP server where users control what the LLM can do. The agentic-workflows governance patch [6] will go to the next TC meeting for discussion. Time ran out before the room could resolve whether service projects should add AGENTS.md files or whether the agentic-workflows project should become a community goal. We'll take up these topics in the TC's IRC meetings in the coming weeks. PQC Compliance ~~~~~~~~~~~~~~ jjung (Jean-Philippe Jung) led this session, framing post-quantum cryptography as a regulatory risk: US regulations are emerging that would block procurement of products without quantum-safe crypto by 2027, and telecom and financial deployments will face regulations first. Red Hat has assessed all active OpenStack repos, developed custom detection rules using OpenGrep, and published initial patches for Barbican and Keystone. TheJulia pushed back on the "boil the ocean" framing of the problem. She proposed concrete building blocks instead: consistent TLS version and cipher configuration knobs across all services, which she's already implementing in Ironic. gmaan raised backward compatibility concerns, asking whether the goal is to add quantum-safe support alongside existing algorithms (acceptable) or to reject non-quantum-safe algorithms (hugely breaking). jjung confirmed: enable pqc safety, don't enforce. JayF tied this back to VMT resourcing. The VMT is drowning in new security vulnerability reports. His frustration was that PQC and FIPS compliance efforts arrived with regulatory urgency and executive enthusiasm, but the everyday VMT vulnerability triage work doesn't get the same investment. He asked what he needs to do as co-security SIG chair to attract a higher level of engagement for the "boring" stuff. I connected this to the FIPS precedent, where regulatory urgency drove initial effort that eventually died, leaving broken test infrastructure the TC had no mechanism to formally end. The room agreed to form a pop-up team with defined scope and champions before pursuing community goal status. cardoe (Doug Goldstein) proposed that the PQC pop up team work on an attack tree documentation so operators can understand which vectors matter for their deployment. Governance & Open Discussion ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ I presented two governance topics. First, refreshing the TC's vision document [7], which hasn't been substantively updated since 2019. Without a current vision, every question on a deviation gets relitigated from first principles. Most recently, the questions have asked if Rust can be used as a programming language, if pytest can be used as a test framework, should AI services be included within OpenStack, etc. clarkb (Clark Boylan) framed it well: the vision should assert why OpenStack exists, not prescribe the how; Python is an implementation detail. JayF pushed for a vision that extends beyond OpenStack, noting that almost every deployment today also runs Kubernetes, Ceph or other related open source software. TheJulia drew on visioning training she undertook with the TC in 2018, stressing aspirational thinking and scatter-gather for ideas rather than jumping straight to Gerrit patches. sean-k-mooney added that his concern with adding Rust was never the language itself but that the proposal sidestepped the established process for adding languages. I proposed a Contributor Experience Working Group to revive the dormant First Contact SIG and Upstream Institute efforts. The working group would serve as a contributor advocacy group, making recommendations to the TC. One of its first tasks could be to reform the Extra ACs process. I noted that the current process had a lot of "friction". There have been about 14 proposals made in a decade. Maybe the Working Group can think about dropping the extra AC mechanism from the TC entirely and letting project teams recognize contributors with ease, though electorate implications need further discussion. We then moved to open discussion. JayF proposed a SECURITY.md for all OpenStack repos because GitHub currently tells visitors we have "no security policy." because we lack a markdown file in our repository. cardoe suggested a different approach: a .github org-wide config repo that covers security policy, contributor redirect, and org landing page in one place. JayF and cardoe will collaborate on the implementation. Org-wide config repo also supports other GitHub metadata (security.md, contributing.md, code_of_conduct.md, support.md, governance.md). GitHub also recently added the ability to fully disable pull requests and this would be helpful to us. On Python 3.14 based end-to-end testing, croelandt (Cyril Roelandt) described his container-based testing approach against python release candidates, clarkb noted existing pyenv support in Zuul tox jobs, and sean-k-mooney shared a UV-based DevStack POC that already uncovered real eventlet-related bugs. Thank you all for participating to make this yet another successful virtual "design summit". We have a lot of action items to unpack. As we make progress through these, I'll share updates through the TC's weekly correspondence. -- Goutham Pacha Ravi (gouthamr) OpenStack TC Chair [1] TC 2026.2 PTG Etherpad: https://etherpad.opendev.org/p/r.6b585b1d6ee0c6b5d500d5344ea637ca [2] TC YouTube playlist: https://www.youtube.com/playlist?list=PLhwOhbQKWT7VMSRlyvfJ1eBsl8BjPFNpp [3] UPP Etherpad: https://etherpad.opendev.org/p/UPP-Projects%26Mentors [4] Launchpad hygiene audit: https://gist.github.com/gouthampacha/2e31f5127a907e6c59d357cf98dc35e2 [5] OpenStack wiki operators page: https://wiki.openstack.org/wiki/Operations [6] Agentic-workflows governance patch: https://review.opendev.org/c/openstack/governance/+/984958 [7] TC Vision document: https://governance.openstack.org/tc/reference/technical-vision.html

1 0

[nova] Nova Spec & Specless Blueprint Deadlines for 2026.2 Hibiscus
by René Ribaud 27 Apr '26

27 Apr '26

Hi everyone, The Nova deadlines for 2026.2 Hibiscus have been merged [1]. A quick heads-up on one clarification: The Spec Soft Freeze and Spec Freeze deadlines now explicitly cover specless blueprints as well. This has always been the case in practice, but was never stated in the schedule, which caused some confusion during Gazpacho. This was discussed and agreed upon at the PTG. Key dates: - Spec Review Days: May 21 & June 4 - Spec Soft Freeze: May 28, 2026 — no new specs or specless blueprints accepted - Spec Freeze: June 11, 2026 — all specs and specless blueprints must be approved If you're planning any feature for Hibiscus, spec or specless, please plan accordingly. Full schedule: [2] René [1] https://review.opendev.org/c/openstack/releases/+/985791 [2] https://releases.openstack.org/hibiscus/schedule.html

1 0

[OSSA-2026-008] Command Injection in Ironic IPMI Console Implementations
by Jay Faulkner 27 Apr '26

27 Apr '26

======================================================================= OSSA-2026-008: Command Injection in Ironic IPMI Console Implementations ======================================================================= :Date: April 27, 2026 :CVE: CVE-2026-pending Affects ~~~~~~~ - Ironic: >=4.3.0 <26.1.6, >=27.0.0 <29.0.5, >=30.0.0 <32.0.1, >=33.0.0 <35.0.1 Description ~~~~~~~~~~~ Dmitry Tantsur and Tuomo Tanskanen from the Metal3.io Security Team reported a vulnerability in Ironic's IPMI console backends. A project manager for the project marked as a ``node.owner`` can inject arbitrary commands which a conductor executes on console activation. No console backends are enabled by default in Ironic. Only installations which have set ``[conductor]/enabled_console_interfaces`` to enable either ``ipmitool-shellinabox`` or ``ipmitool-socat`` are vulnerable. Patches ~~~~~~~ -https://review.opendev.org/c/openstack/ironic/+/986418 (2023.1/antelope (unmaintained)) -https://review.opendev.org/c/openstack/ironic/+/986417 (2024.1/caracal (unmaintained)) -https://review.opendev.org/c/openstack/ironic/+/986363 (2024.2/dalmatian) -https://review.opendev.org/c/openstack/ironic/+/986362 (2025.1/epoxy) -https://review.opendev.org/c/openstack/ironic/+/986361 (2025.2/flamingo) -https://review.opendev.org/c/openstack/ironic/+/986235 (2026.1/gazpacho) Credits ~~~~~~~ - Dmitry Tantsur from Metal3.io Security Team - Tuomo Tanskanen from Metal3.io Security Team References ~~~~~~~~~~ -https://launchpad.net/bugs/2148331 Notes ~~~~~ - A CVE request was filed with MITRE on 2026-04-27. - Patches for unmaintained branches are provided as a courtesy. - The ``ipmitool-shellinabox`` console interface is already scheduled for removal from Ironic for lack of security support for shellinabox. Security sensitive operators are strongly encouraged to stop use of this console interface immediately. Thanks, Jay Faulkner OpenStack Vulnerability Management Team Ironic Security Liason

1 0

[nova][ptg] 2026.2 Hibiscus PTG summary
by René Ribaud 27 Apr '26

27 Apr '26

Hello everyone, Last week was the PTG, thank you to all who joined and contributed to the discussions! I hope you enjoyed it and found it productive. This cycle we had another packed agenda with active participation throughout the sessions. For the Nova sessions (Monday to Friday), we had an average of 15 to 20 participants per session. Attendance was slightly higher during the cross-project discussions, with an average of 25 to 31 participants, especially the Ironic session. You can revisit all notes and discussions on the Etherpad here: https://etherpad.opendev.org/p/nova-2026.2-ptg Below is a summary of the topics and outcomes from our PTG discussions. I've tried to keep it as concise as possible, though we covered quite a lot during the week. **** Monday topics **** #### 2026.1 Gazpacho Retrospective #### 2026.1 Gazpacho results: - Blueprints: 11 Accepted, 9.33 Implemented (84%) - Bugs: At least 28 bugfixes merged For comparison, 2025.2 Flamingo had 14 accepted blueprints with 9 implemented (64%) and at least 26 bugfixes merged. Release closure proceeded smoothly post-Feature Freeze with minimal CI issues. The only exception involved a pkg_resources issue outside Nova's control. The approach of accepting fewer, smaller tasks proved more predictable than previous cycles. ✅ Core +2 on a spec includes implicit commitment to reviewing the implementation. ✅ Upstream meetings should explicitly communicate priorities and readiness status. ✅ Bug tracking for eventlet removal work via Launchpad tags. #### 2026.2 Hibiscus Proposed Planning #### The team agreed on the following schedule: - Spec review day: May 21 - Soft spec freeze: May 28 - Spec review day: June 4 - Hard spec freeze: June 11 - M2: July 2 - Feature review day: August 4 - Feature review day: August 20 - Feature Freeze at M3: August 27 - Release: End of September / early October ✅ Adopt the proposed timeline, moving soft freeze two weeks earlier and scheduling review days one week before deadlines. ### Start cross session with Cinder ### #### Assisted Volume Extend #### The team discussed how to handle volume extend for file-based volume drivers (such as NFS) that require hypervisor assistance. Four options were analyzed (A through D), ranging from async callbacks to a generic assisted-volume-action API. ✅ Proceed with a hybrid approach combining Options A and B. ✅ Complete Cinder and client-side work first. ✅ Ensure required Nova API microversion availability during Cinder calls. ✅ Use OpenStack SDK (novaclient no longer receives support for newer API microversions). #### Expose Quiesce/Unquiesce API #### The team discussed creating a new API for quiesce/unquiesce instance volumes callable from Cinder, independent of snapshot operations. ✅ Create new API for quiesce/unquiesce instance volumes callable from Cinder. ✅ Support list of volumes for consistency groups. ✅ API should be asynchronous but with success/failure reporting capability. ✅ Require new specifications for both Nova and Cinder projects. ### End cross session with Cinder ### ### Start cross session with Manila ### Good progress was made since the last cycle. The SDK change and the OpenStack Client update have both merged. Testing has also progressed, with scenario test specifications merged and active work on Tempest modifications, virtiofsd installation in Manila devstack, and scenario tests for both VirtioFS attachments and hot attach. #### Hot Attach/Detach with VirtioFS #### Hot attach serves as prerequisite for live migration capability. The main discussion focused on whether a new API microversion is needed, since the request/response body doesn't change only the server-side precondition (allowing "active"/"paused" states instead of only "shutoff"/"error"). ✅ New microversion preferred as a feature availability marker, especially considering in-progress upgrade scenarios with mixed host states. #### Live Migration with VirtioFS Attachments #### The team discussed requirements (virtiofsd >= 1.11, QEMU >= 9.x, libvirt >= 10.x) and scope of blocked operations (unshelve, evacuate, rebuild, resize). ✅ Create two separate specifications for cold and live migration to decompose the workload. ✅ Cold migration absence represents an operator blocker that needs to be addressed. #### Memfd Support #### Adds hw:memory_backend flavor extra spec enabling per-instance shared memory backing selection (memfd/file/hugepage/anonymous). This enables OVS-DPDK and virtio-fs support, reducing the complexity. ✅ Make memfd the default immediately for new instances rather than a two-phase rollout. ### End cross session with Manila ### **** Tuesday topics **** ### Start cross session with Cyborg ### A more complete summary of this joint session will be provided by the Cyborg team, as they can better capture the discussions and decisions made. Reference: https://etherpad.opendev.org/p/cyborg-2026.2-ptg#L404 ### End cross session with Cyborg ### ### Start cross session with Ironic ### A more complete summary of this joint session will be provided by the Ironic team, as they can better capture the discussions and decisions made. On a lighter note, there was a historic and somewhat surreal moment during the session where Dan and TheJulia actually agreed on a topic, and Sean said something positive about OTU. 😄 ### End cross session with Ironic ### #### Unpinning Availability Zone #### The team discussed how to release instances pinned to specific AZs, preventing emergency migrations. Multiple approaches were considered. ✅ Allow setting the request_spec AZ to None or to the instance's current AZ to unpin. ✅ Default policy: admin-only. ✅ Document possible side effects of AZ unpinning. ✅ Preference for consistent behavior across all move operations. #### PCI Grouping #### Moving from "single device per alias" to "logical group of devices" is requested and scheduled as a single unit. Extensive discussion on traits (union approach), device types, PF/VF dependencies, resource class overrides, group lifecycle, and upgrade path. ✅ Union traits from grouped devices, devices within groups become non-consumable individually. ✅ Support multiple VFs from the same PF in different groups. ✅ Reject adding devices to allocated groups at compute startup. ✅ Handle device disappearance similarly to non-grouped devices. ✅ No reshape required; rolling upgrades supported. ✅ gibi, taking the primary implementation role, with Sylvain and Sean as main reviewers. #### Supporting Different Resource Classes for VFs (GPU/MIG Use Case) #### Modern GPUs (NVIDIA H100 with MIG) use SR-IOV to expose different compute profiles as VFs under a single PF. The current Nova implementation prevents assigning different Resource Classes to these VFs. ✅ Team not opposed, specification required. ✅ Coordinate with gibi to prevent PCI Grouping conflicts. ✅ Priority for this work needs to be defined. **** Wednesday topics **** #### Confidential Computing: AMD SEV-SNP Support #### Multiple parties report SEV-SNP running in production. The LY implementation is available and needs rebase on master. ✅ Start from LY implementation, refine via iteration. ✅ Takashi to update specification regarding hw_firmware_stateless definition. ✅ Avoid in-Nova workarounds for firmware; leverage libvirt detection. ✅ Documentation should describe firmware file modification requirements when needed. ✅ Omit idAuth/idBlock/hostData parameters from initial specification. #### Confidential Computing: TDX Spec Review #### Discussion covered TDX requirements (host passthrough, UEFI firmware limitations) and how to handle default memory-encryption model selection. The team really appreciated the quality of the presentation on this topic. ✅ Mandate hw:mem_encryption_model specification for TDX (not addressing default logic within this spec). ✅ Use Placement reservations for TDX key tracking rather than auto-detection. ✅ Document UEFI firmware limitation regarding SCSI driver stack. #### SEV Refactoring Remaining Issues #### The conflict between hw:mem_encryption=true and hw:locked_memory=False was discussed. ✅ Documentation patch to clarify interaction and expectations. #### Eventlet Removal #### Significant progress since Gazpacho. Remaining work includes console proxy conversion, CLI/nova-manage handling, deprecation statement, config option conversion, and full test coverage. ✅ Kamil volunteered to drive the Eventlet removal effort in Hibiscus. ✅ Explore generic eventlet import prevention (possibly via oslo). ✅ Verify novnc architecture in eventlet mode before conversion. ✅ Current Rally perf-test proposal represents the starting point; significant additional scenario work is needed. ### Start cross session with Horizon ### A more complete summary of this joint session will be provided by the Horizon team, as they can better capture the discussions and decisions made. Reference: https://etherpad.opendev.org/p/apr2026-ptg-horizon#L127 ### End cross session with Horizon ### #### Cross-AZ Scheduling Weigher #### The team discussed a weigher proposal for AZ-aware scheduling. Multiple concerns were raised about the approach. ✅ The pain point is understood, but the proposed weigher solution lacks fit. ✅ Alternative approaches involving server groups API or unified hard anti-affinity policies merit further exploration. ✅ No weigher adoption, topic requires further discussion. #### Add Typing #### The team discussed adopting type hints in Nova. Majority of dependencies now include type hints. ✅ Set ignore_errors = false for non-test code. ✅ Don't target strict typing. ✅ In conclusion, we have reached a consensus: type hints are welcome and should not be a reason for rejection. However, we reserve the right to push back if the hints provide no tangible benefit, the criteria for which will be refined over time. **** Thursday topics **** #### AI/LLM Knowledge and Hard Rules #### Discussion on adding knowledge prose and hard rules to Nova repository for LLM-aware development. ✅ Keep Nova knowledge in Nova repo without duplication. ✅ AGENTS.md should be minimal and point to in-repo documentation. ✅ Separate LLM-specific information from human-readable content. ✅ Prefer deterministic checks (scripts, linters, fixtures) over LLM prose guidance. ✅ Information useful to both humans and LLMs should live in documentation. ✅ Bring broader OpenStack governance questions about AI assistance to the TC and Board. #### Send os-server-external-events via SDK Instead of Novaclient #### Projects (Neutron, Cyborg, Cinder) send notifications to Nova via os-server-external-events API using novaclient. OpenStack SDK currently lacks this API. ✅ Add service-to-service API to SDK. ✅ Lajos to discuss with Stephen about sharing knowledge for similar API usage elsewhere. #### Bidirectional RPC Liveness Handshake #### Under certain conditions, Nova-Compute loses the ability to receive RPCs while the heartbeat continues, and the compute appears alive despite being unable to process requests. ✅ Specification accepted. ✅ Two-step implementation: unconditional first, then optimized. ✅ Failure threshold requirement; optimize later. ✅ Address timeout values, failure thresholds, and echo request pileup concerns in the spec. #### TempURL Usage in Nova #### The team briefly discussed the proposal for TempURL usage in Nova. ✅ General agreement on the approach. #### Attestation Integration #### Rather than Nova performing attestation, an external service will maintain host attestation traits. Nova auto-deletes these traits on startup, signaling unknown state. ✅ Define trait prefix (e.g., HW_ATTESTATION_*); Nova auto-deletes on startup. ✅ External service maintains traits at runtime. ✅ Flavors request/require traits for secure-node-only boot. ✅ Watcher may implement this via proxy service. #### Barbican Secret Handling for vTPM Live Migration #### Nova creates Barbican secrets for 'deployment' TPM security mode using Nova service user credentials. Barbican defaults allow any service project member to decrypt, which is broader than intended. ✅ Leave current design; operator responsibility. ✅ Melwitt to add documentation details/warnings/clarity to vTPM docs. **** Friday topics **** Note: Friday sessions were limited (13:00-14:00 UTC only) due to TC and Board meeting conflicts. #### Nova-Reviewers and Nova-Approvers Split #### Sean proposed adopting the Ironic/SDK model with separate nova-reviewers (+2) and nova-approvers (+W) groups. Extensive discussion followed on review bandwidth, core expansion, and how to increase patch landing velocity. The team debated multiple perspectives: - Expanding the reviewer base with proven subsystem experts - Aggressively adding full cores rather than creating a split - Concerns about lowering the landing bar ✅ No final decision reached, the team broadly agrees on the need to expand review capacity. ✅ Core expansion and mentoring remain the preferred path forward. ✅ Further discussion needed, potentially in private follow-up. #### Standardize Service-to-Service Communication #### We skipped this topic due to time and Gmann constraints. We will revisit this probably in an upstream meeting. #### Nova Ephemeral Volumes Using NetApp FlexGroup #### The team discussed a proposal for using NetApp FlexGroup as a backend for Nova ephemeral volumes. ✅ There are major concerns about the proposal. ✅ The approach looks somewhat hacky and could introduce technical debt in the future. A proper driver would be a better approach. ✅ Significant concerns were also raised about CI coverage. ✅ The team is not comfortable including a vendor-specific backend. Vendor neutrality will always be the preferred approach. ✅ A new spec proposal addressing these concerns will be welcome and discussed. #### Metadata/Tag Protection #### The team discussed the proposal for protecting instance metadata and tags from unauthorized modifications. ✅ Globbing preferred over regexp for pattern matching. ✅ Sean to leave notes in the spec and continue to refine it. ✅ Adding a concrete use case to the spec would be helpful to define the proper solution. If you've read this far, thank you! If you spot any mistakes or missing points, please don't hesitate to let me know. Best regards, René.

1 0

[nova][bug triage] Bug Triage Meeting - Tuesday April 29th
by René Ribaud 27 Apr '26

27 Apr '26

Hi all, Apologies for the late notice. The next Nova bug triage session will take place on Tuesday, April 29th. Here is the link to join: https://meet.google.com/fdz-phux-cnc As a reminder, this meeting is public and open to everyone. It's easy to join the roster. Feel free to add yourself: https://etherpad.opendev.org/p/nova-bug-triage-roster If you'd like to be added to the calendar invite for this meeting, feel free to ping me. Best regards, René

1 0

[cyborg] 2026.2 (Hibiscus) Virtual PTG Summary
by Sean Mooney 27 Apr '26

27 Apr '26

Hi all, As many of you may be aware the OpenStack community has a Project Team Gathering event every release cycle. I'm happy to report that the Cyborg team held its 2026.2 virtual PTG session last week and I would like to thank all who participated. Below is a summary of the topics covered, decisions made, and open questions where wider community input is welcome. Full notes are at: https://etherpad.opendev.org/p/r.bb485b94c3487349f2e36eb4e3b5a2ce Testing ------- A significant portion of the session was spent on the state of testing across the project. The conclusion is that coverage gaps are wide and need a structured effort to close. Driver support levels: We agreed to adopt formal driver support levels: supported, experimental, deprecated, and removed. All current in-tree drivers will be marked experimental immediately except the fake driver. Drivers that remain experimental for more than one release will be downgraded to deprecated after a mailing-list callout for maintainers. Cyborg will emit a start-up warning for drivers that are not at the "supported" level. As testing and documentation is built out for existing drivers they will graduate to supported over time. Exact details of the support levels will be captured in new project docs to set clear expectations for operators and developers. Once a deprecated driver has been announced in a SLURP release it can be removed in a following release. Tempest plugin: A dedicated etherpad will be created to coordinate cyborg-tempest-plugin improvements. Current gaps include missing stable test IDs, microversion tests, and per-driver scenario tests (today only one scenario test exists and it is hard-coded to the fake driver). PCI driver testing may be possible using the nvmevirt simulator or a third-party CI via RDO zuul. Functional testing: Building out functional test infrastructure (end-to-end tests within a single process against SQLite, similar to Nova's functional tests) was agreed as an aspirational goal for this cycle. A blueprint will be created; whether a full spec is needed is TBD. Contributor documentation will accompany it. python-cyborgclient: The v1 API code will be dropped this cycle; v2 Python bindings and the freestanding cyborg CLI will be formally deprecated in favour of the OpenStack SDK and OSC plugin. New test coverage will be built only around the OSC and sdk code path. Opens: Whether temporary operator-supplied test reports remain acceptable long-term and what minimum evidence they should contain; whether per-driver tempest tests become a hard gate for new drivers. Tech Debt --------- Several cleanup and scalability items were agreed for this and upcoming cycles. SRBAC: All phases will be implemented in 2026.2 (admin, manager, member, reader, and service roles). The new policies will become the default in 2027.1; legacy policies will be deprecated for removal in 2027.2, the exact details of this will be captured in a new spec. Conductor decoupling: Placement interactions should be moved to the compute agent; simple API CRUD operations should bypass the conductor RPC entirely. The conductor is currently a global single point of failure and scaling concern because cyborg does not support cells or conductor group for internal sharding of compute agents. The evolution of this will take time and thought and as such may be deferred to a later cycle. Quotas: The existing quota system is non-functional and will be replaced with Keystone unified limits. Cyborg must enforce quota on ARQ bind before device-profile on server create can be supported. Priority of this new capability is TBD and will partly depend on usage/operator feedback. Image verification: The feature was never fully implemented and depends on Nova objects that were never ported. Agreed to remove it and re-implement it from scratch with proper test coverage and documentation. With that said we may decide to fix it in place if that proves quick and back-portable. OpenStack SDK: Cyborg will port its glance interaction to the SDK, removing the python-glanceclient dependency. API design: The device, attribute, and deployables APIs have overlapping responsibilities and should be consolidated into a single surface. PATCH with JSON Patch payloads should be replaced with PUT. OpenAPI request and response schemas should be introduced. This cycle: produce a single design document. API evolution (microversion or v3) targeted for a future release. The only concrete change landing this cycle is removing stale references to the removed v1 API from the API reference. Documentation: New features must ship a release note and docs in the same series. New drivers must include a driver-specific admin doc and a cross-link to the support matrix. We also agreed to produce a service interaction doc covering how cyborg, placement, and nova work together. Opens: How to signal enabled/disabled device state to the Nova scheduler. reserved=total vs placement traits both have precedent but different trade-offs around admin reservations and per-resource granularity. Using reserved=total is likely the correct path but we need to document why and how that works. Nova Cross-Project ------------------ We met with the Nova team to align on work that requires changes in both projects. VM lifecycle (resize, cold/live migration): Gaps for stateless devices will be investigated this cycle with a PoC if time allows. The feature is targeted at 2027.1. Stateful device support (e.g. NVMe disk content transfer) is deferred to 2027.1+. For resize-revert, the expectation is that the source ARQ is held until the resize is confirmed and the destination ARQ is held until a revert is discarded via resize confirm. Attachment handles: An mdev handle type is needed for time-sliced vGPU support (Nova spec already in review). Handle content will need to carry live_migratable and managed metadata that would normally come from the nova.conf via the PCI devspec. Additional future types (nvme, block, usb, cxl) are scoped but not targeted this cycle. Device-profile on server create and attach/detach: Both have a soft dependency on unified limits support landing in cyborg first. Targeted at 2027.1+ after resize is supported. Nova scheduler extensibility: Not discussed due to time. The MVP proposal is to expose provider summaries to existing filters and weighers via the host state object. Longer-term proposals for stevedore extension points and hook points were mentioned as nice to have operator quality of life improvement for out-of-tree use cases (watcher policy-based scheduling, cyborg NUMA filtering, telemetry-aware scheduling). Opens: Whether a generic configurable traits weigher in Nova, or moving weighing logic to Placement, could satisfy the extensibility use cases without requiring out-of-tree hook infrastructure is still open. New Drivers ----------- Two new drivers are moving forward this cycle alongside early groundwork on a longer-term v2 driver framework. Generic MDEV driver: The existing NVIDIA driver will be refactored to reuse it. First-party CI testing will use the mtty/mdpy kernel modules. The companion Nova spec for mdev attach-handle support is already in review. NVMe driver: It will inherit from the generic PCI driver, use nvme-cli for device management and secure erase, and will not require the pci or SSD driver to be enabled to function. Details will be in the sepc. Generic driver framework v2: Agreed to PoC the concepts incrementally in the new MDEV and NVMe drivers this cycle, factoring out PCI enumeration and introducing typed data classes in place of generic dicts. No spec this cycle; a formal spec targeting 2027.1 will follow if the PoC succeeds. We also agreed to rename the whitelist config option to align with Nova's devspec so that shared keys behave consistently across both projects. Placement traits and RP naming: The convention CUSTOM_<BUS>_<vendor_id>_<product_id> (aligning with Nova's PCI-in-placement work) was proposed and discussed but no formal agreement was reached this cycle. Interchangeable VFs should be grouped into a single RP per NUMA node per device type rather than reported as individual RPs of inventory 1. A spec with an upgrade path is required before any of this lands. TBD if this will be done as part of the v2 generic driver work or independently; no ETA is proposed for this work. Opens: NUMA modelling in placement requires agreement with Nova on the RP naming convention and UUID generation before cyborg can create NUMA resource providers independently. If you have questions or feedback on any of the above, please reply to this thread. Thanks to everyone who participated in the sessions. regards Seán p.s. as with most of my longer prose to this list this has been translated form sean speak to english via llm assistance, enjoy the added punctuation and capital letters.

1 0