Enforce zero plugin refcount during disable, not remove.#29599
Enforce zero plugin refcount during disable, not remove.#29599anusha-ragunathan merged 1 commit intomoby:masterfrom
Conversation
|
LGTM |
|
I'm not sure this is right. |
|
For instance, in the |
|
If the plugin is buggy, what good is it to have a reference to it? Not having an enabled plugin, when there are resources (volumes, networks, etc) referencing them, is not a good model. |
|
@anusha-ragunathan I'm remembering my sysadmin days, monitoring the memory usage of a particularly leaky daemon that I'd have something automatically restart once it hit a certain limit while waiting for a patch to come in. |
|
@cpuguy83 : Does it make sense to have a |
|
@anusha-ragunathan I suppose it would, given that |
c87962c to
6420081
Compare
plugin/backend_linux.go
Outdated
There was a problem hiding this comment.
Can we keep this refcount check?
When plugins have a positive refcount, they were not allowed to be removed. However, plugins could still be disabled when volumes referenced it and containers using them were running. This change fixes that by enforcing plugin refcount during disable. A "force" disable option is also added to ignore reference refcounting. Signed-off-by: Anusha Ragunathan <anusha@docker.com>
6420081 to
8cb2229
Compare
|
Experimental failure is due to Hub issues. windows failure is unrelated. |
Enforce zero plugin refcount during disable, not remove.
Enforce zero plugin refcount during disable, not remove.
When plugins have a positive refcount, they were not allowed to be
removed. However, plugins could still be disabled when volumes
referenced it and containers using them were running. This change fixes
that by enforcing plugin refcount during disable and not remove.
Signed-off-by: Anusha Ragunathan anusha@docker.com
Part of fix for #29447