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