-
Notifications
You must be signed in to change notification settings - Fork 154
Description
Following discussion on opencontainers/oci-conformance#36, I am trying to see how to use runtime-tools to test containerd.
I am exploring how to write a wrapper around containerd implementing the OCI Runtime Command Line Interface that runtime-tools would use as a $RUNTIME
to talk to containerd.
containerd's ctr
CLI tool can run
(create+start) a container or start
it. There is no CLI for creating one without starting it but it can be done both at the gRPC level or using the Golang client library.
CLI command cdr task start
does the following:
- calls the
NewTask()
method from the client library. This calls the gRPC commandc.client.TaskService().Create()
- calls the
task.Start()
method from the client library. This calls the gRPC commandt.client.TaskService().Start
``
runtime-tools tests don't download images from internet but instead they create the config.json
and the rootfs
themselves with the specific configuration that need to be tested. However, the containerd interface mostly deals with images. It is possible to call create
in the gRPC protocol and include config.json
on the wire but the root.path
will unfortunately not be respected in the last version. A fix is in progress (containerd/containerd#2412, containerd/containerd#2418, thanks @flx42 and @crosbymichael!).
Since runtime-tools tests have no control over which directory containerd will write the config.json
received by gRPC, the rootfs prepared by runtime-tools tests will not be in the same directory. This contradicts the OCI specs (see @flx42's comment) but containerd might allow absolute paths in root.path
outside of the bundle anyway, so that might be ok for the containerd wrapper to rely on that.