1:50 p.m.
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.
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