On 6/3/20 01:23, Peng Tao via Podman wrote:
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.
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 .
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.
A PR would go a long way to helping us to decide. I don't see anyone on
the podman team able to work on this at this time.
>> 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 . 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.
> Matt Heon
>> 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
>  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