Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
[1.13-rc2] cannot use existing volumes if plugin is upgraded; volume is bound to a plugin ID #28913
A volume that is created in a volume plugin, causes docker to cache the plugin ID that it was created / referenced with. If that plugin ID changes (volume plugin is removed, re-added. Or volume plugin is upgraded), then all of the volumes associated with the previous version of the plugin can no longer be used.
Steps to reproduce the issue:
Describe the results you received:
Describe the results you expected:
The existing volumes created / referenced with previous versions of the plugin should have worked without an issue. The plugin ID should be re-validated without requiring a docker restart. Docker restart should never be required to clear caches, or otherwise recover from normal system operation. The next time the
Additional information you deem important (e.g. issue happens only occasionally):
Additional environment details (AWS, VirtualBox, physical, etc.):
@srust : The volume is indeed pinned to the pluginID (aka volume driver ID in this case). That is precisely why you cannot remove a plugin, when a volume created out of it, is active. I'm surprised that you were able to remove the volume plugin, while the volume was in use. Is the plugin used in step 1 a v1plugin? If yes, then that's expected.
Also, with #28717, you also cannot create a plugin which has a duplicate name with an existing plugin.
On master, I tried to reproduce the issue you are facing with and the daemon works and errors out as expected.
Hi @anusha-ragunathan, thanks for the response.
What you say is true. If the plugin is enabled, it cannot be removed (without a --force). And if you attempt to create or install a plugin with an existing name it will fail. That is all correct behavior, as you have outlined.
The issue is when a user actually does want to do an upgrade, and how a user may do that. I'll try to be specific so that I can get feedback on the exact use-case.
Let's say a plugin
Now, imagine a new plugin is released. This could be a bugfix, security update, specific feature enhancement, etc. A plugin could be upgraded for many valid reasons.
To upgrade the plugin, the user may perform the following steps:
The new version of the plugin shows the volume just fine:
But it cannot use it, because
(NOTE: In the above example,
It is my assertion that:
It seems to me that on plugin rm, any volumes referencing it should have their references removed. While that is not ideal from a potential performance perspective (walking the volume cache), and is not great if that volume is used while the plugin is down, it does at least allow the
Can you please comment on the above example and assertions and help me where there is any misunderstanding?
So, to me it sounds like we are missing a case here.
As @srust mentioned, being able to upgrade a plugin is going to be a common case, and not necessarily desirable to remove a plugin in order to install the upgraded one.
This unties the plugin lifecycle from the actual process management.