[Podman] Re: RFC: non-CLI integration with OCI-runtimes

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/de... >> >> 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(a)lists.podman.io >> To unsubscribe send an email to podman-leave(a)lists.podman.io