What is the problem you're trying to solve
I want to be able to manage a system where the runtime implementing shim-v2 API does not need to exist at a predefined location, with a predefined name.
Describe the solution you'd like
Add a runtime path option to the plugins.containerd.runtimes configuration so I can register a v2 runtime with a specific name and path on the host.
Additional context
I had opened this issue before, but I don't think the suggested solution meets my use case: #3073 My fault for waiting two years to fully evaluate this!
As an example, I'm utilizing a daemonset, kata-deploy, to install Kata Containers across a cluster. It is likely possible that the containerd configuration on a given node will already be utilizing /opt/containerd for plugins.opt, whereas my daemonset is looking to install the shim-v2 runtime at /opt/kata. With the current design, this leaves me with two options, which imo are not ideal:
- hostMount /usr/local/bin. I can then either create symlink or install the binary there. (downside: I would very much like to avoid touching this path on a running system).
- hostMount /opt/containerd and installing there (downside: I don't want to assume that this already is being used, and I don't want to risk modifying existing containerd configuration/plugins in this path).
It'd be a lot cleaner if instead I can install the artifacts at our own location, /opt/kata, and simply add a configuration file fragment through imports to introduce the runtime configuration, which would include the runtime type, path, and configuration. Suggested example:
[plugins."io.containerd.grpc.v1.cri".containerd.runtimes.kata]
runtime_type = "io.containerd.kata.v2"
runtime_path = "/opt/kata/bin/kata-shimv2"
privileged_without_host_devices = true
[plugins."io.containerd.grpc.v1.cri".containerd.runtimes.kata.options]
ConfigPath = "/opt/kata/share/defaults/configuration.toml"
In summary, I'd like to be able to use the fully qualified path rather than:
- Assuming file is in PATH already, and
- Assuming the file name format
What is the problem you're trying to solve
I want to be able to manage a system where the runtime implementing shim-v2 API does not need to exist at a predefined location, with a predefined name.
Describe the solution you'd like
Add a runtime path option to the plugins.containerd.runtimes configuration so I can register a v2 runtime with a specific name and path on the host.
Additional context
I had opened this issue before, but I don't think the suggested solution meets my use case: #3073 My fault for waiting two years to fully evaluate this!
As an example, I'm utilizing a daemonset, kata-deploy, to install Kata Containers across a cluster. It is likely possible that the containerd configuration on a given node will already be utilizing /opt/containerd for plugins.opt, whereas my daemonset is looking to install the shim-v2 runtime at /opt/kata. With the current design, this leaves me with two options, which imo are not ideal:
It'd be a lot cleaner if instead I can install the artifacts at our own location, /opt/kata, and simply add a configuration file fragment through imports to introduce the runtime configuration, which would include the runtime type, path, and configuration. Suggested example:
In summary, I'd like to be able to use the fully qualified path rather than: