Shimv2 and CRI-O clarifications
Hi, hoping somebody can clear up a couple of points of confusion for me. 1) The shimv2 protocol AIUI, the shimv2 protocol has basically the same semantics as the OCI runtime spec, but is over gRPC instead of a command line interface. Is that correct? Is there somewhere to find the spec of the shimv2 protocol? 2) CRI-O "runtime_type" option The CRI-O configuration has a "runtime_type" variable for each runtime, with options of "oci" or "vm". What exactly the difference between those is kind of unclear: what docs I've found say that "vm" is more suitable for VM based runtimes, but I can't really see any reason that would make a difference for crio. Looking at the code it looks like "vm" switches CRI-O to use the "shimv2" grpc based interface rather than command line. It makes sense CRI-O would need to know that, but AFAICT it has nothing whatsoever to do with whether the runtime uses a VM. -- David Gibson | I'll have my music baroque, and my code david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_ | _way_ _around_! http://www.ozlabs.org/~dgibson
David, On Thu, Feb 11, 2021 at 4:54 AM David Gibson <kata-dev@gibson.dropbear.id.au> wrote:
Hi, hoping somebody can clear up a couple of points of confusion for me.
1) The shimv2 protocol
AIUI, the shimv2 protocol has basically the same semantics as the OCI runtime spec, but is over gRPC instead of a command line interface. Is that correct? Is there somewhere to find the spec of the shimv2 protocol?
Not exactly. There's a bunch of APIs that are the same, but it's not a 1:1 relationship. Please, refer to the following document for more details: https://github.com/containerd/containerd/issues/2426
2) CRI-O "runtime_type" option
The CRI-O configuration has a "runtime_type" variable for each runtime, with options of "oci" or "vm". What exactly the difference between those is kind of unclear: what docs I've found say that "vm" is more suitable for VM based runtimes, but I can't really see any reason that would make a difference for crio. Looking at the code it looks like "vm" switches CRI-O to use the "shimv2" grpc based interface rather than command line. It makes sense CRI-O would need to know that, but AFAICT it has nothing whatsoever to do with whether the runtime uses a VM.
My guess is that it inherited its "vm" name because the shimv2 proposal had in mind VM based runtimes. As you mentioned, CRI-O has to know it's dealing with "shimv2", and that's pretty much about it. Best Regards, -- Fabiano Fidêncio
participants (2)
-
David Gibson
-
Fabiano Fidêncio