elections-2025-04: What is the most important thing (be it an integration, a particular feature, adopting a policy, etc) Kata Containers needs to achieve this year and how should we get there?

[ildikov]

This is the first question for the campaign period of the 2025-04 Kata AC elections.

cc @ananos @bergwolf @RuoqingHe @stevenhorsman @zvonkok

[pmores]

(say runtime-rs! ;-))

[zvonkok]

One significant priority is maintaining high-quality documentation, regardless of which features we develop. We must focus on improving and updating documentation across all aspects of the project. This need is especially pronounced in our work with Confidential Containers, where we currently have overlapping content covering the same topics.
As more organizations explore both Kata and Confidential Containers, insufficient documentation will deter potential adopters. In addition, we should expand our CI/CD to include well-documented use case examples, showing exactly what we run and how we run it to help new users replicate configurations in their own environments.
I am currently enabling a simple RAG pipeline, feeding in the Kata documentation (mostly HTML docs), and asking the inference service questions about Kata.
Depending on those answers and questions, we can fine-tune our documentation, a feedback loop integrated into our CI/CD.

[ananos]

+1 to improving documentation, especially for non-mainstream devices like Jetsons and other edge boards, where clearer guidance could unlock broader adoption. No1 priority for me in the coming weeks!

One of the most important things Kata Containers needs to achieve this year is to level up its testing and CI infrastructure. This isn’t just about stability, it’s about enabling faster iterations, more confident contributions, and better support for integration scenarios. Today, Kata powers multi-tenant workloads for many providers, but if we want to keep pace with evolving use cases, we need to understand why downstream branches exist and aim to support more deployment environments, starting with better tests and more flexible CI pipelines.

Equally important is improving observability. Metrics and introspection across the full stack should be treated as first-class features, not afterthoughts. A few steps in this direction:

(a) Expose structured, actionable metrics from the runtime, VMM, and guest, including boot times, CPU/mem usage, I/O performance, and lifecycle events.

(b) Enable seamless integration with time-series databases for analysis and visualization.

This is especially critical for adopters running Kata in high-scale or dynamic environments—where understanding cold start behavior, sandbox performance, and failure modes without having to shell into the guest is essential for operating with confidence.

[RuoqingHe]

My focuses are primarily three fold:

• Improving the stability of our CI infrastructure, especially the RISC-V ones. I will extend the runner matrix in Kata self-hosted RISC-V runners, since we are closely working with RISC-V hardware vendors, so we can easily get hold on those machines.
• Expand RISC-V support for Kata components. I will continue to work out, stabilize and maintain RISC-V architecture support all over the place, and work with RISC-V hardware vendors to test and run Kata software stack on their products properly.
• Explore RISC-V Confidential Containers. I am looking for works could/should be done in both coco community and integrating them to Kata, and catching up the developments of CoVE here.

RISC-V is maturing, IPs with H ext., AIA and IOMMU are already delivered, SoCs are going to be manufactured in Q4 of this year. I believe RISC-V is going to bloom and Kata-Containers could gain more audience with it. Then, there will be contributors from hardware vendors, OS distros and end users of Kata on those hardware/OSs, our community is bound to grow. To achieve this, I've been advocating Kata on RISC-V for half a year, I brought the topic to more than 10 different meetups/summits. I talked about Kata on RISC-V in FOSDEM 2025 [1] in Feb 2025, I will bring this topic to RISC-V Summit Europe 2025 [2] in May 2025 and wherever I go.

[1] https://fosdem.org/2025/schedule/event/fosdem-2025-4156-from-rust-vmm-to-katacontainers-the-development-of-h-ext-based-software-ecosystem/
[2] https://riscv-europe.org/summit/2025/

[gkurz]

CoCo is an ambitious and impressive project but it is still experimental at this stage and it needs enough flexibility to continue to thrive. We saw how it could be very invasive in Kata-Containers on many aspects, e.g. unsettled design decisions, urge to merge, bumping of toolchain or pulling of dependencies only useful for CoCo. This was partly discussed during last vPTG.

I'd like to get some thoughts from my future AC colleagues on how we can ensure Kata-Containers manages to be a production grade software for the enterprise world and the vehicle of choice for bleeding edge technologies such as CoCo ?

[stevenhorsman]

I agree with many of the comments above, particularly around improving documentation and publicizing use-cases more effectively as I think those help bring new users into the community more effectively and we want to be outwards as well as inwards focusing, especially with the move to the Linux Foundation potentially giving us new eyes.

Also in that vain I think improving the "professionalism" of upstream is very important for the next year, for both new users and making the life of our current users and downstreams better. By this I mean driving security and versioning standards to try and ensure we don't have any CVEs (at least in "supported" parts of the project), bumping versions to ensure that crates and go modules are not 5/6 years old and setting up policies around these updates so that people know what to expect. I think that security tools like scorecard/OpenSSF badge are helpful to keep us honest and transparent about the things we do well and need improving.