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

[openstack-ansible] Cancelling today's meeting
by Dmitriy Rabotyagov 28 Apr '26

28 Apr '26

Hi folks, Sorry for the short notice, but due to mine unavailability I have decided to cancel today's meeting. See everyone next week!

1 0

[manila] 2026.2 Hibiscus PTG summary
by Carlos Silva 28 Apr '26

28 Apr '26

Hello, stackers. Here's a summary with some context on the topics we discussed, as well as the decisions and action items we took during the 2026.2 Hibiscus PTG. In case you would like to revisit those discussions, the sessions were recorded and are available in the OpenStack Manila Youtube channel [1] and all notes and topics are available in the PTG etherpad [17]. *All things CephFS [2]* ================= *CephFS QoS - opted for qos types approach* --------------------------------------------------------------- CephFS NFS QoS will be implemented as a driver-only change leveraging Manila's existing QoS Types framework (v2.94+) to support bandwidth and IOPS throttling at the NFS-Ganesha level. The implementation will support three simplified spec keys (max_read_bw, max_write_bw, max_iops) and apply QoS after NFS export creation. Implementation is currently blocked awaiting upstream Ceph MGR PR merges, requiring testing with bleeding-edge Ceph builds. We are planning a PoC for this feature possibly in the 2026.2 Hibiscus release. *Erasure coded pools* ----------------------------- Erasure Coded pool support will be enabled through a new cephfs:data_pool share type extra-spec that passes pool_layout to Ceph's subvolume creation command. This allows operators to leverage EC pools for capacity-sensitive workloads (large files, streaming, archival) while maintaining replicated pools for metadata and small-file workloads. With k=4,m=2 configuration, this can potentially double usable capacity compared to 3-way replication while maintaining the same fault tolerance, requiring no API, database, or scheduler changes. The Manila team is working on the testing and the necessary changes for enabling this feature, having 2026.2 Hibiscus as a target. *BYOK encryption* ------------------------ BYOK encryption support is in exploratory phase to test end-to-end at-rest encryption workflows with an open-source driver. The main challenge is integrating CephFS's fscrypt model, which lacks built-in KMS interaction and operates per-subvolume without the concept of share servers, with Manila's current encryption framework. The team is evaluating whether Manila can orchestrate secret handover (simple but exposes user secrets) or whether KMS knowledge should be added to Ceph itself. We would like to take the design choices to the Ceph community. *DNS Configuration for SVM in DHSS=True Mode [3]* *=========================================* In DHSS=True mode, the NetApp ONTAP driver doesn't configure DNS on newly created SVMs, causing share encryption to fail because the SVM cannot resolve Barbican/Keystone endpoint hostnames needed for key retrieval. The NetApp team is proposing two approaches: one introducing manila.conf configuration options for the DNS entry creation in the SVMs and a share network subnet metadata approach. We shared our concerns regarding the UX around the second approach, considering that users should not fix infrastructure issues. We agreed that we will introduce the configuration options for addressing this behavior. The NetApp team is currently working on it. *NetApp AFX Integration [4]* *======================* NetApp AFX is a disaggregated NAS platform with a shared storage pool (SAZ) architecture requiring REST-only API access, targeting high-performance AI/ML workloads with ONTAP 9.17.1+. The team discussed whether to create a separate driver for AFX or extend the existing NetApp ONTAP driver, considering the implications on share migration; the plan is to update the current driver with platform detection, though share migration is not feasible for AFX due to its single-pool architecture and the current driver's limitation to intra-cluster migrations only. *Eventlet Removal* =============== We covered the progress we made in the Gazpacho release with both introducing the option to run oslo.threading instead of eventlet and all the changes that were needed, as well as the testing we did so far. For 2026.2 Hibiscus, our plan is to - Look to test with at least one other WSGI server alternatives (gunicorn). - Complete privsep migration to address the rootwrap incompatibility with eventlet - Switch the default execution mode to disable eventlet and monkey patching - Merge the new rally job that does compares eventlet based execution to native threading mechanism [5] - Increase our test coverage and introduce new test scenarios - Be ready for the removal in 2027.1 "I". *Share migration graduation* *=======================* We discussed what should be done and the testing needed for making the share migration feature (implemented years ago) transition away from an experimental status. We also discussed about the need for our team to create guidelines for feature graduation. AI: the Manila team will come up with a plan and documentation and set a target to how long APIs can remain in "experimental" state. *Weka driver [6]* *============* In this topic, we discussed integrating Weka parallel filesystem with OpenStack Manila for GPU clusters. The approach consists of creating a "Mosaic" bridge component that maps Manila's share model to Weka's filesystem model using a "fileset" abstraction. We shared the requirements and how to introduce new supported share protocols. We suggested that this should be added as a new third party driver with a CI system for testing. The contributors will check the requirements but will also weigh in if this should be a whole new OpenStack service altogether. *Manila NetApp Driver: ZAPI-to-REST Migration Gaps [7]* *=============================================* The NetApp engineering team has been working on a multi cycle effort to migrate the calls to NetApp storages away from a proprietary tool, directing them to REST calls. Such migration resulted in some gaps both for incompatibilities in modes and unavailability in the REST mode for NetApp. In this topic, the NetApp team shared a detailed analysis on the gaps, comparing the urgency of each issue and what needs fixing in the storage. *Enhancing health checks in Manila [8]* *===============================* We discussed implementing lightweight in-process HTTP health endpoints (/health) for Manila services that passively track real service capabilities (database, RPC, backend drivers) instead of just heartbeat liveness, enabling better Kubernetes probes and monitoring. This approach is similar to what the Nova team is working on. AI: fpantano will propose a specification for it. *Graceful shutdowns [9]* *===================* The manila team is planning on enhancing the shutdown mechanisms. As part of this topic, gouthamr presented enhancement plans for auto-recovering shares and resources stuck in transient states (creating, deleting, migrating, etc.) when manila-share crashes mid-operation, using startup/periodic reconciliation to check backend reality and either complete or error-out abandoned operations. The team shared feedback on this approach and asked for a possibility of giving drivers more control over the process. AI: gouthamr will propose a specification. *New Manila Driver for HPE Storage [10]* *================================* We discussed driver requirements and addressed questions from HPE engineers. The HPE storage in question lacks read-only access (RW-only) and share quotas (unbounded growth). Read-write only is acceptable initially, but for quotas: the team shared the feature should be available in ~3 months in HPE. We advised waiting on the next storage release to avoid breaking UX changes later, and use granular access states instead of erroring out entire update_access calls. The driver can be iterated through on gerrit in the meantime. Target: Hibiscus cycle. *Netapp SnapMirror Active sync support (share server replication) [11]* *=========================================================* We discussed constraints for introducing share server replication API support in OpenStack Manila, as well as support for it in the NetApp ONTAP driver through SnapMirror Active Sync (SMAS), enabling zero RPO/RTO share server-level replication with new APIs/CLIs for replica management (create, promote, resync). We agreed that this feature should be admin-only, following other share server APIs, to avoid breaks in the UX and workflows, as well as smooth and transparent changes in the promotion process. gireesh, Anoop_Shukla_ and KumarT will incorporate the feedback to the proposal and propose a spec. *Cross project session with Nova* *===========================* We discussed the progress we made with regards to the share attachment feature (VirtioFS) and shared our plans for the upcoming cycles. We recently merged the remaining SDK [12] and OSC [13] changes, making the OSC commands available for consumption. The Manila team also worked on implementing scenario (end to end) tests [14] and proposed them in a new gerrit change. Our plans for 2026.2 Hibiscus include merging the hot attachment [14], live migration [15] and cold migration [16] specs and start working on the implementation. [1] https://www.youtube.com/@openstackmanila [2] https://etherpad.opendev.org/p/hibiscus-ptg-manila-cephfs [3] https://etherpad.opendev.org/p/DNS_Configuration_for_SVM_in_DHSS_True_Mode [4] https://etherpad.opendev.org/p/manila-netapp-afx-support [5] https://review.opendev.org/c/openstack/rally-openstack/+/974559 [6] https://etherpad.opendev.org/p/weka-driver [7] https://etherpad.opendev.org/p/manila-netapp-rest-gaps [8] https://etherpad.opendev.org/p/manila_healthcheck [9] https://etherpad.opendev.org/p/manila_healthcheck#L310 [10] https://etherpad.opendev.org/p/manila-hpe-storage [11] https://etherpad.opendev.org/p/netapp-manila-active-sync-support [12] https://review.opendev.org/c/openstack/openstacksdk/+/880056 [13] https://review.opendev.org/c/openstack/python-openstackclient/+/881540 [14] https://review.opendev.org/c/openstack/nova-specs/+/983816 [15] https://review.opendev.org/c/openstack/nova-specs/+/983801 [16] https://review.opendev.org/c/openstack/nova-specs/+/985738 [17] https://etherpad.opendev.org/p/hibiscus-ptg-manila Thank you, carloss

1 0

[kolla] Cancelling Kolla weekly meeting on 29th Apr 2026 (tomorrow)
by Michał Nasiadka 28 Apr '26

28 Apr '26

Hola Koalas, Due to my unavailability (and probably most people recovering from PTG last week) - I’m cancelling this weekly meeting (29th Apr 2026). See you on 6th of May! Michal

1 0

[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