Description
Plugin registration does not enforce uniqueness of plugin IDs. This leads to an issue when attempting to disable plugins because when plugin.Graph loops through the registered plugins to match against the disabled list, it only removes the first plugin with a given ID (presumably on the assumption of uniqueness of plugin IDs).
I'm opening this issue to:
- have a place to discuss whether or not uniqueness should be enforced in code rather than by convention and
- to propose addressing the one occurrence of duplicate plugin names I'm aware of -- the
GRPCPlugin and ContentPlugin both named "content".
Steps to reproduce the issue:
- List
"content" in the disabled_plugins slice in the containerd config file
- Start and stop containerd a few times. Observe that because of registration order, it is not deterministic which of the plugins get disabled.
Describe the results you received:
It is not possible to disable a specific one of either the GRPCPlugin or ContentPlugin named "content" reliably.
Describe the results you expected:
Disabling a plugin by providing it's ID in the config file.
Output of containerd --version:
containerd github.com/containerd/containerd v1.2.0-473-g5f4c977b 5f4c977ba0c44d6e12a0907251ca133954f0c82d
Description
Plugin registration does not enforce uniqueness of plugin IDs. This leads to an issue when attempting to disable plugins because when
plugin.Graphloops through the registered plugins to match against the disabled list, it only removes the first plugin with a given ID (presumably on the assumption of uniqueness of plugin IDs).I'm opening this issue to:
GRPCPluginandContentPluginboth named "content".Steps to reproduce the issue:
"content"in thedisabled_pluginsslice in the containerd config fileDescribe the results you received:
It is not possible to disable a specific one of either the
GRPCPluginorContentPluginnamed "content" reliably.Describe the results you expected:
Disabling a plugin by providing it's ID in the config file.
Output of
containerd --version: