Options not passed to shim when run via ctr

[ianlewis]

Description

config.toml looks like this.

disabled_plugins = ["restart"]
[plugins.linux]
  shim_debug = true
[plugins.cri.containerd.runtimes.runsc]
  runtime_type = "io.containerd.runsc.v1"
[plugins.cri.containerd.runtimes.runsc.options]
  TypeUrl = "io.containerd.runsc.v1.options"
  ConfigPath = "/etc/containerd/runsc.toml"

Steps to reproduce the issue:

1. Run a container with ctr run --rm --runtime io.containerd.runsc.v1 docker.io/library/alpine:latest foo echo bar

Describe the results you received:
Options set in config.toml are not passed to shim. Shim receives nil Options in the CreateTaskRequest request.

Describe the results you expected:
Options should be set on the CreateTaskRequest and include data in config.toml.

Output of containerd --version:

containerd containerd.io 1.3.7 8fba4e9a7d01810a393d5d25a3621dc101981175

[kzys]

ctr command is calling containerd without using CRI. I'm unsure these plugins.cri.* options are supposed to be used.

[ianlewis]

That seems a bit odd given the the runtimes themselves are defined as a cri configuration: plugins.cri.containerd.runtimes.*

[ianlewis]

My thought it that the --runtime flag for ctr should either include the options when invoking the shim or not exist. As a shim author we can't really implement a shim to work properly in this case if not given the options. Users will be rightfully confused when it doesn't work.

[dmcgowan]

@ianlewis ctr is just a development tool which directly uses the containerd client, it does not utilize anything inside the cri plugin today. crictl is the only way to call into the cri plugin today and use anything configured via plugins.cri.*.

That being said, we have now merged containerd/cri codebase back into containerd/containerd. It is still a separate plugin today but our plan is to spin out parts of it into the core. To be utilized by ctr anything spun out would have to be utilized either behind new APIs or integrated into existing services.

I am going to mark this as a feature request since the requested functionality is not implemented today. I am assuming you want this to work and not just mark it as something we should document as not working :)

[ianlewis]

I'm aware of cri being a plugin but I'm a bit confused. Given that the target of ctr's --runtime flag is (or can be) configured via plugins.cri.* and that it is supported in ctr, I would assume it would also pick up the options. i.e. If I add plugins.cri.containerd.runtimes.myruntime to my config and ctr run --runtime=io.containerd.myruntime.v1 ... works, I would assume that adding plugins.cri.containerd.runtimes.myruntime.options would also work.

[windniw]

@ianlewis

Given that the target of ctr's --runtime flag is (or can be) configured via plugins.cri.* and that it is supported in ctr, I would assume it would also pick up the options.

I am confused in it. You use ctr run --runtime=io.containerd.myruntime.v1 ... instead of ctr run --runtime=myruntime .... It looks like ctr may not pick up the config in plugins.cri.* but directlly use io.containerd.myruntime.v1 in command.

[ianlewis]

@ianlewis

Given that the target of ctr's --runtime flag is (or can be) configured via plugins.cri.* and that it is supported in ctr, I would assume it would also pick up the options.

I am confused in it. You use ctr run --runtime=io.containerd.myruntime.v1 ... instead of ctr run --runtime=myruntime .... It looks like ctr may not pick up the config in plugins.cri.* but directlly use io.containerd.myruntime.v1 in command.

I'm not sure what you mean. ctr run --runtime=myruntime just plain doesn't work afaik since that's not the runtime name from ctr's perspective. https://github.com/containerd/containerd/blob/main/runtime/v2/README.md#binary-naming

You simply can't set a shim config path when not using CRI because the shim config path is a CRI plugin feature (the code just isn't there), even though you should theoretically be able to set a config because shim's aren't a CRI thing.