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

[tc][all] Proposal: minimal agentic coding scaffold for OpenStack projects
by Sean Mooney 15 Apr '26

15 Apr '26

Hi all, I wanted to share a lightweight, cross-project approach to supporting AI coding assistants in OpenStack repositories and get community feedback before the PTG next week. Two early implementations are available for review: Nova (more complete): https://review.opendev.org/c/openstack/nova/+/984540 Watcher Dashboard (earlier iteration, needs further refinement): https://review.opendev.org/c/openstack/watcher-dashboard/+/983334 Background ---------- AI coding assistants have become part of many contributors and reviewers day-to-day workflow. Most tools support some form of context file (AGENTS.md, CLAUDE.md, .cursorrules, Copilot instructions, etc.) that you drop at the repository root to guide agent behaviour. Without one, agents fall back to generic assumptions that do not match our projects' conventions: they reach for pytest instead of stestr, propose GitHub PRs instead of Gerrit reviews, or omit the Generated-By / Assisted-By trailers required by the OpenInfra Foundation AI policy [1]. The risk of doing nothing is that every contributor ends up maintaining their own private prompt file, those files diverge, and the community gets no shared benefit from what contributors learn and reviewers cant have a way to enforce there expectations automatically before they are asked to review. Philosophy: tell the agent to RTFM ---------------------------------- The core idea is to keep the scaffold minimal. If a convention must be followed, it should be documented in human-readable prose that agents can find through normal file exploration, not in a separate AI-curated summary that can drift from the authoritative source. In practice: - AGENTS.md is a routing index, not a rulebook. It points to HACKING.rst, the contributor docs, tox.ini, and other canonical sources rather than duplicating them. - Agents are expected to read the actual project documentation, the same way a new human contributor would. - The file is kept short (under 100 lines), which also keeps it token-efficient when injected into agent context windows. The per-project content is whatever would genuinely mislead an agent without it: tooling gotchas, workflow specifics, routing pointers to where the real rules live. The structure and philosophy are shared across projects. What each project adds ----------------------- The scaffold is a small, consistent set of files: 1. AGENTS.md: the routing index. Content is project-specific; the role and conventions are shared. Kept under 100 lines. 2. CLAUDE.md: a symlink to AGENTS.md. Not all tools support the same filename: most support AGENTS.md natively, but some (including Claude Code) look for CLAUDE.md instead. The symlink means both filenames resolve to the same content with nothing to keep in sync. 3. ai/: a gitignored directory for agent session memory, plans, scratch notes, and ephemeral files. Agents are directed to prefer ai/tmp/ over the system temp directory so that all agent file I/O stays inside the repo tree, visible to the developer and sandboxed from shared system space. Only ai/.keep is committed. 4. A contributor doc (e.g. agentic-coding.rst) documenting the conventions and the AGENTS.md philosophy. This is what agents read when they follow the routing pointer; the project's own docs carry the detail. 5. Optionally, a repo-overview doc with a terse map of the repository layout, primarily for human orientation. The Nova review is the more complete reference implementation. The Watcher Dashboard review is an earlier iteration that still needs refinement but shows the approach applied to a different project. Intentional scope ----------------- This proposal is limited to the scaffolding layer: AGENTS.md routing, the ai/ session directory, and the contributor docs. It does not propose in-repo skills, subagents, or shared prompt libraries. I think the community needs more time to learn how to build and maintain such tools effectively before we standardise on anything. What this scaffold does is enforce project preferences at the routing level while leaving contributors free to experiment locally with whatever agent tooling works for them. Vendor neutrality ----------------- The scaffold is tool-agnostic. AGENTS.md [2] is the emerging cross-tool standard, now stewarded by the Agentic AI Foundation under the Linux Foundation, with native support across Cursor, Codex, Aider, and others. Tools that do not support AGENTS.md typically support CLAUDE.md instead, which is why the symlink covers both cases with a single file to maintain. No tool names appear in the committed documentation; examples use generic placeholders. Any contributor, with any AI assistant, should get the same benefit. The contributor doc also documents how to express the Foundation AI policy [1] as standard git footers, keeping disclosure information in a consistent, machine-readable location without adding new obligations. Discussion questions for the PTG and the list --------------------------------------------- 1. Does this philosophy seem right: minimal scaffold, agents read the actual project docs? Or should projects invest in richer inline context files? 2. Is there value in the TC providing a cross-project baseline so projects do not each start from scratch? The openstack/hacking repository, which already owns shared coding standards, seems like a natural home for a baseline AGENTS.md that projects extend. Im Interested in views on that vs a new repo or just good old copy pasta 3. Are there common gotchas shared across OpenStack projects (Gerrit workflow, DCO, stestr, pbr) that belong in such a baseline rather than being repeated per-repo? I think a shared PTG topic or including it in similar planed topics could be a good way to facilitate wider discussion. i had planed to bring it up in the nova/watcher/cyborg sessions if there was time to see how open each team was to this proposal. Feedback on the reviews or on this thread is equally welcome. regards sean [1] https://openinfra.org/legal/ai-policy [2] https://agents.md/ (Agentic AI Foundation / Linux Foundation) ps yes this has been proofread by ai which is why its in english with punctuation not sean speak ... mostly

4 5

[openstack][share]Openstack Workload Balancer
by Nguyễn Hữu Khôi 15 Apr '26

15 Apr '26

Hello, I have a script to make Openstack workload balance(CPU and RAM). I would like to share it. This script is not perfect but I hope it will be useful for you. https://github.com/nguyenhuukhoi/OpenstackWBalancer Nguyen Huu Khoi

1 1

[cinder][nova][ceph] Cinder encryption happens at QEMU layer, not librbd — significant overhead, seeking direction
by Ravi Sasi Tilak 15 Apr '26

15 Apr '26

Hi all, We're running OpenStack with Ceph RBD as the Cinder storage backend and need encryption at rest with per-tenant key isolation. We've evaluated two approaches: 1. Cinder volume encryption Per-volume keys stored in OpenBao via Castellan. Cinder formats the RBD image with a LUKS header and QEMU handles decryption at attach time. The problem is that encryption always happens at the QEMU layer — Nova's libvirt driver doesn't set the engine to librbd, so encryption/decryption never happens inside librbd where it would be most efficient. It stays at the QEMU block layer, adding significant overhead. We're seeing 60-80% IOPS reduction in our testing. 2. Ceph librbd-native LUKS encryption Encryption happens inside librbd itself — client-side, per-image keys, data encrypted before it leaves the compute node. This is architecturally the right place for Ceph to do encryption. But there's no integration with external key managers — rbd_encryption_load() requires the passphrase directly from the caller, making it impractical for multi-tenant environments that need centralized key management. The gap: - Cinder encryption: per-tenant keys ✓, KMS integration ✓, performance ✗ (encryption at QEMU layer, not librbd) - librbd-native: performance ✓, per-image keys ✓, KMS integration ✗ What's the community's recommended approach for Ceph + OpenStack deployments that need per-tenant encryption keys with acceptable performance? Are we missing something, or is this a known gap? Happy to contribute if there's a path forward. Thanks, Ravi Sasi Tilak

3 2

[cinder] Idea: CBT interface for backup drivers
by 홍인용 15 Apr '26

15 Apr '26

Hi all, I would like to suggest improving Cinder's incremental backup efficiency by introducing a Changed Block Tracking (CBT) interface. Currently, incremental backups read the full volume and rely on chunk-level SHA256 hashing to detect changes. Even when only a small portion of the volume has changed, a full scan is still required, which impacts performance and resource usage. Some backends like Ceph (rbd diff) and NetApp (SnapDiff) already have native APIs for tracking block-level changes. I believe it is worth exploring a standardized CBT interface at the backup driver level to take advantage of these capabilities—with a fallback to the current hashing method for drivers that do not support it. I am interested in exploring this further and would appreciate your thoughts on this approach or if there have been similar discussions in the past. Thanks, inyong hong(hong-p)

3 2

[zun][kolla] Zun Deployment with Docker Version Constraints in Kolla-Ansible 2023.1
by Thamanna Farhath 15 Apr '26

15 Apr '26

Hi openstack community, I am working on deploying Zun using Kolla-Ansible (OpenStack 2023.1 – Antelope) and came across a known limitation in the documentation: Kuryr does not support Docker 23+ due to the removal of the --cluster-store option. Suggested workaround is to pin Docker to version 20.x using: docker_apt_package_pin: "5:20." docker_yum_package_pin: "20." My current setup: Existing cluster running Docker 29.x (no Zun) I want to avoid downgrading Docker on existing nodes Clarifications needed: Can we run mixed Docker versions (existing compute nodes on 29.x, new compute nodes with Zun on 20.x)? Is it safe/recommended to use dedicated compute nodes only for Zun with Docker 20.x? Is this issue still open, or are there alternatives? Looking for best practices to enable Zun without impacting the current cluster Thanks & regards, Thamanna Farhath Disclaimer : The content of this email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to which they are addressed. If you have received this email in error, please notify the sender and remove the messages from your system. If you are not the named addressee, it is strictly forbidden for you to share, circulate, distribute or copy any part of this e-mail to any third party without the written consent of the sender. E-mail transmission cannot be guaranteed to be secured or error free as information could be intercepted, corrupted, lost, destroyed, arrive late, incomplete, or may contain viruses. Therefore, we do not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. The recipient should check this e-mail and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email."

1 0

[vitrage][tc] Deprecation of the Vitrage project
by Dmitriy Rabotyagov 14 Apr '26

14 Apr '26

Hi everyone, After evaluating the current state of the Vitrage project [1] and its alignment with the community's activity standards, the Technical Committee (TC) has decided to deprecate the project. This decision was based on several factors regarding the project's health and sustainability: - The project has been without a Project Team Lead (PTL) for an extended period, leaving it without a clear roadmap or technical direction. - The project has been marked as Inactive since the 2026.1 cycle [2], and according to the Inactive project criterias, the time of retirement has approached. - The project has been excluded from the 2026.1 release due to inactivity What this means for users: - With merge of the retirement proposal [3], the project will be marked as Deprecated. - There will be no new major releases or further project development - Security patches, or critical bug fixes may be provided by the OpenStack community for the Vitrage stable branches, until all stable releases are moved to unmaintained state. - All content for master branch will be removed and replaced with a placeholder Important note: under the umbrella of the Vitrage project, there are multiple xstatic libraries, including: - dagre - dagre-d3 - graphlib - lodash - moment These xstatic libraries above will be deprecated along with the Vitrage project. I have tried my best to check usage of libraries outside of Vitrage, and it seems that Venus dashboard is the only one depending on some of these. If your project is depending on one of these libraries, please reach out to the Technical Committee as soon as possible. We would like to thank the past contributors who dedicated their time and effort to Vitrage over the years. Your work has been a valued part of the OpenStack ecosystem. For those interested in the historical code or documentation, the archives will remain available in the Git repository. In case there is any interest from the community to continue the maintenance or revive the project in the future, please reach out to the Technical Committee. [1] https://wiki.openstack.org/wiki/Vitrage [2] https://governance.openstack.org/tc/reference/emerging-technology-and-inact… [3] https://review.opendev.org/c/openstack/governance/+/982869

1 0

Re: Update on RDO: A Shift to Containers
by Jose Castro Leon 14 Apr '26

14 Apr '26

We are also heavily affected by this change, as all our deployments at CERN rely on it. Moreover, we are early adopters of RDO and now that we are getting into Epoxy release, it just slips away. The deployment model is not something you can easily change. Does it also mean that our el10 users may never have client libraries packaged to use our setups? And following Massimo remark, will the repo be maintained while it's still in supported status in OpenStack? If not, are you implying that we also need to repackage future security updates? Thanks, Jose CERN Cloud Team ________________________________ From: Massimo Sgaravatto <massimo.sgaravatto(a)gmail.com> Sent: Thursday, March 5, 2026 1:40 PM To: Amy Marrich <amy(a)demarco.com> Cc: RDO Developmen List <dev(a)lists.rdoproject.org>; openstack-discuss <openstack-discuss(a)lists.openstack.org>; users(a)lists.rdoproject.org <users(a)lists.rdoproject.org>; Mike Burns <mburns(a)redhat.com> Subject: Re: Update on RDO: A Shift to Containers A non-negligible impact for our deployment :-( So, as far as I understand, no rpms will be released for the F and G releases, correct? Will you keep releasing updated RPMs for the Epoxy release, while it is in the maintained status, or the repo https://mirror.stream.centos.org/SIGs/9-stream/cloud/x86_64/openstack-epoxy/ will not be updated anymore ? Thanks, Massimo On Wed, Mar 4, 2026 at 4:19 PM Amy Marrich <amy(a)demarco.com<mailto:amy@demarco.com>> wrote: Dear RDO Community/Stakeholders, This email provides an important update regarding the RDO project and its future direction which marks a significant change in how RDO content will be delivered. End of RDO RPM Builds Historically, RDO provided RPM-based rebuilds of upstream OpenStack packages. Due to insufficient contributors, the continuous RDO rpm builds that were released through the CentOS Cloud SIG have been officially discontinued as of the Epoxy release. Introducing the New RDO: Container Focus The future of RDO will be focused entirely on containers. This is a pivot from our traditional RPM delivery, as RDO did not previously focus on containers. RDO will be transitioning to Source-to-Image (S2I) builds for service containers. This work will be starting shortly within the <http://github.com/openstack-k8s-operators> github.com/openstack-k8s-operators<http://github.com/openstack-k8s-operators> organization, and these new container builds will essentially be the "new RDO". Timeline and Usage: * This transition work has not yet begun. The timeline is not committed, but the work is currently expected to be available for the Hibiscus release in late 2026. The final delivery location of those images is still to be determined. * These containers are primarily intended to be consumed via the operators provided in the openstack-k8s-operators GitHub organization. * While nothing explicitly prevents these containers from being used elsewhere, this is not currently part of the plan. Community involvement and feedback for broader usage are welcome including within OKD and the okderators. * Please note that the operators in this organization are currently only developed and tested on Red Hat OpenShift Container Platform. Thank you for your understanding and continued support as we make this important shift. We look forward to engaging with the community on this new path forward. Sincerely, Amy

5 4

[openstackclient][all] Nova-network removal in OSC
by Brian Haley 14 Apr '26

14 Apr '26

Hi, While doing some other cleanup in the openstackclient network code, I noticed there were still places where it had Nova-network compatibility. I have proposed a patch to remove it all at [0], but Stephen reminded me that there could be users that need this (Rackspace? [1]) and as the client should support all clouds, removing it might break them. From what I can remember it was in the Havana cycle in 2013 that Neutron became the standard and maybe Newton (?) where we started to de-emphasize Nova-network. Is that a long enough time to call something obsolete and remove it? Please respond here or in the review if this is a bad idea, it's currently blocked with a -2 so it doesn't merge. Thanks! -Brian, Neutron PTL [0] https://review.opendev.org/c/openstack/python-openstackclient/+/981613 [1] https://docs-ospc.rackspace.com/cloud-networks/v2/

2 1

[ironic] Proposing Clif Houck as an ironic-reviewer
by Jay Faulkner 14 Apr '26

14 Apr '26

Hey all, I was performing the semi-annual reviewer-review for Ironic projects this cycle, and I have a proposal for an addition to ironic-reviewers group: Clif Houck (also from GR-OSS). Clif was #8 overall this cycle with 54 total reviews. He's also provided valuable feedback with a -1 on a handful of patches already. I'd like to suggest he be granted ironic-reviewer access, as trust him to have discretion to only use the +2 in portions of the codebase he has familiarity in. I will execute this change as soon as Monday of next week if there are no objections. Thanks, Jay Faulkner G-Research Open Source Software

2 1

[openstack-helm] Nominate Mathieu Gagné as a core reviewer
by Vladimir Kozhukalov 14 Apr '26

14 Apr '26

Hi team, I’d like to nominate *Mathieu Gagné* as a core reviewer for the OpenStack-Helm project. He has been actively contributing since February 2026 and has brought many valuable ideas and improvements to the project. Feedback and comments are welcome. -- Best regards, Kozhukalov Vladimir

2 1