On 2020/6/3 02:50, Matt Heon wrote:
On 2020-06-02 18:30, Eric Ernst via Podman wrote:
Hey pod-folk –
In the Kata Containers community, for 2.0 Kata we are looking to *just* support integration through a gRPC server/client interface, utilizing the ‘v2-shim’ API. This is how we integrate with CRIO/containerd, and we are now looking at do similar for both moby and Podman. Hello,
Please allow me to add a few background for the change. Before the v2-shim API, we have runc like command line (kata-runtime) that would end up with one kata-shim process per IO stream for a pod. The life cycle of the kata-shim process is identical to the IO stream. That means we at least have to keep running one kata-shim per container in a pod and possibly more with one kata-shim per container exec. And it leads to kata-shim process explosion and causes a lot of management troubles for sysadmins and SREs in production. Luckily enough, we migrated from the above architecture to a much simpler v2-shim architecture, where there is only one shimv2 process per pod. The transition is also illustrated in picture [1]. For podman, while it is working with the kata-runtime command line, we would like to encourage you to also migrate to the v2-shim API to make it easier for users to adopt podman + Kata, and help them avoid the kata-shim process explosion problem. It is really important from production users point of view. Cheers, Tao [1]. https://raw.githubusercontent.com/kata-containers/documentation/master/desig...
I wanted to get feedback from Podman community on whether integrating through v2shim server/client between podman/kata is:
1. Technically feasible
Our general contract for an OCI runtime is that it must fulfill the inteface at [1]. The biggest things there that Kata may not implement: - We need to be able to run a specific Podman command (provided by Podman when the container is started) when a container exits. - We need the OCI runtime to write a file containing the container's exit code when the container exits (as ASCII, not binary).
(These two also apply to exec sessions, but that is less critical IMO)
These don't necessarily have to be done by Kata itself - if they can be worked into a wrapper service, that's perfectly fine by us, but we do need both of them to ensure core Podman functionality.
Other things (attach stream format, if it's different) can be coded around in the actual implementation of an OCI runtime that talks to Kata via this gRPC interface.
My other concern would be that there's no expectation of asyncronous communication from Kata - without a daemon, we don't have anything that can listen for messages from Kata.
2. A design pattern ya’ll are amenable to.
So long as the implementation fits into our OCI runtime interface (and we'd be happy to consider modifications to that interface, if they're needed), I think this sounds fine. If this ends up dragging in any large dependencies that increase binary size significantly, I'd want to gate it behind a build tag, but otherwise I don't see any problems.
Thanks, Matt Heon
Thanks, Eric
CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, is for the sole use of the intended recipient(s) and contains information that is confidential and proprietary to Ampere Computing or its subsidiaries. It is to be used solely for the purpose of furthering the parties' business relationship. Any review, copying, or distribution of this email (or any attachments thereto) is strictly prohibited. If you are not the intended recipient, please contact the sender immediately and permanently delete the original and any copies of this email and any attachments thereto.
[1] https://github.com/containers/libpod/blob/master/libpod/oci.go
_______________________________________________ Podman mailing list -- podman@lists.podman.io To unsubscribe send an email to podman-leave@lists.podman.io
-- Into something rich and strange.