Change:
From the docs.. As of version 2.0, Kata Containers no longer provides an OCI compliant runtime.
Hey do you want the statement to be removed or modify?
/sig security /kind bug
/language en
I'm not sure this issue is valid. For example, states: /priority awaiting-more-evidence /sig node
/triage needs-information
/cc
I have investigated and found that kata version 2 did not support OCI commands or runtime , but from we can clearly see that it has again with the 3rd version of it.
you can look into this thread.
I (still) don't think the website is wrong: Yep, true. As far as I know. Also true. That's fair too. With nothing to actually fix, I propose closing this issue. People who want to see that previous Kata Containers releases dropped OCI compliance should go and look on the Kata Containers website, per
Note that the also states that "Kata Containers 2.5.2 support the OCI Runtime Specification v1.0.0-rc5", although releases prior to 2.5.2 did not. I am a little confused by this claim, as there have been so many issues related to kata =2.0 no longer providing an OCI compliant CLI, thus breaking docker and podman compatibility, so it seemed odd for any doc to claim "Kata Containers is an OCI compliant runtime", which is why I opened this issue. (side note: for a while it looked like kata may re-add the OCI CLI commands via , but a different path to providing an OCI CLI to kata is now being pursued in ) Here's my 2c: The states: So it is possible that kata implements that spec, yet does not implement the . However, according to the docs for : ... where the word "compliance" is a link to the spec that Kata claims to implement. That is saying that for a runtime to be tested for compliance with the runtime spec, it must implement that OCI CLI. It seems reasonable that a runtime can't claim to be OCI compliant, or even compliant with that v1.0.0-rc5 runtime spec, if it does not implement the OCI Command Line Interface which is required to test that very compliance. I'm guessing that this is why Kata carefully worded their statement in the release notes: Note that it says kata "support the" spec, and it does not say "is compliant with" that spec. The k8s documentation, on the other hand, does state that "Kata Containers is an OCI compliant runtime." That seems incorrect based on the reasoning above.
Thanks for the additional context. If Kata Containers doesn't comply with the OCI runtime command line interface, we can fix the wording. You are welcome to provide evidence of this I would focus on whether the latest version of Kata Containers does or doesn't implement the OCI runtime command line evidence; it's also OK to furnish any other evidence that makes it clear that the Kubernetes website is not worded correctly in this respect.
I think the fact that is still open, for the sole purpose of re-enabling an OCI runtime command line interface for kata, is pretty solid evidence that even the latest version of Kata Containers does not implement the OCI runtime command line. It looks like that issue is actively being worked on, so hopefully an OCI interface will exist again at some point. It just doesn't right now.
/triage accepted /remove-priority awaiting-more-evidence /remove-triage needs-information /retitle incorrectly lists Kata Containers as OCI compliant
The actual issue is I'm working on it. I proposed a solution that restored the command lines in the runtime, but that was rejected, so I'm now working on a wrapper that converts command line to shimv2.
That is correct. Part of the problem (at least in my understanding) is that many members of the team consider that supporting the shimv2 interface is sufficient to claim OCI compatibility.
Bottom line is if Kata does not support the OCI Command line then it is just available to CRI-O and Containerd since they run as daemons and implement the Kata Shim API. Podman, buildah and other tools which exec OCI Command line tools can not and will not work with Kata until kata supports an OCI Complient Command line.
In my ideal world someone would build a C Based library for the shim V2 which could link to crun like we have done for crun-wasm and crun-krun, along with standard support in crun.
/assign

Discussion:
* [gVisor](https://gvisor.dev/) intercepts syscalls from containers and runs them through a userspace kernel, written in Go, with limited access to the underlying host. <del> * [Kata Containers](https://katacontainers.io/) is an OCI compliant runtime that allows you to run </del> <ins> * [Kata Containers](https://katacontainers.io/) provide a secure container runtime that allows you to run </ins> containers in a VM. The hardware virtualization available in Kata offers an added layer of security for containers running untrusted code.