Move plugins to shared distribution stack with images.
Create immutable plugin config that matches schema2 requirements.
Ensure data being pushed is same as pulled/created.
Store distribution artifacts in a blobstore.
Run init layer setup for every plugin start.
Fix breakouts from unsafe file accesses.
Add support for `docker plugin install --alias`
Uses normalized references for default names to avoid collisions when using default hosts/tags.
Some refactoring of the plugin manager to support the change, like removing the singleton manager and adding manager config struct.
Signed-off-by: Tonis Tiigi <tonistiigi@gmail.com>
Signed-off-by: Derek McGowan <derek@mcgstyle.net>
Upstream-commit: 3d86b0c79b16334ce5836c0315e4c310b84c2e17
Component: engine
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>
Upstream-commit: 8cb2229cd18c53bdbf36301f26db565a50027d6a
Component: engine
The current GetAll handles both V2 and legacy plugins. Also due to the
nature of V1 plugins, it also loads them. This causes problems when
loading is not required. Hence adding an independent API that will
return only the plugins that are loaded using v2 mangaed plugins.
Signed-off-by: Madhu Venugopal <madhu@docker.com>
Upstream-commit: 8f1b793528e01004e4a40fe4ef835e235282b2f4
Component: engine
This fix is a follow up for comment:
https://github.com/docker/docker/pull/29186/files#r91277345
While #29186 addresses the issue of `docker inspect <unknown object>`
on Windows, it actually makes `docker plugin inspect <unknown object>`
out `object not found` on Windows as well. This is actually misleading
as plugin is not supported on Windows.
This fix reverted the change in #29186 while at the same time,
checks `not supported` in `docker inspect <unknown object>` so that
- `docker plugin inspect <unknown object>` returns `not supported` on Windows
- `docker inspect <unknown object>` returns `not found` on Windows
This fix is related to #29186 and #29185.
Signed-off-by: Yong Tang <yong.tang.github@outlook.com>
Upstream-commit: 0b3c10ac4ddfe3655bac080440a8553269f2307f
Component: engine
Also enables `PropagatedMount` for graphdrivers.
Signed-off-by: Brian Goff <cpuguy83@gmail.com>
Upstream-commit: 500210475f6d841b2eacb42fb495e90108db2733
Component: engine
Fixes a case where removing the plugin from disk would
fail silently. Also moves pluginStore remove after we
remove from disk, so 'docker plugin ls' doesn't isn't
empty in case it errors out.
Signed-off-by: Christopher Jones <tophj@linux.vnet.ibm.com>
Upstream-commit: fb11164c4f71315c96ddf3de46ff4689a5bac59c
Component: engine
Fixes an issue when starting the daemon with live-restore
where previously it was not set, plugins are not running.
Fixes an issue when starting the daemon with live-restore, the plugin
client (for interacting with the plugins HTTP interface) is not set,
causing a panic when the plugin is called.
Signed-off-by: Brian Goff <cpuguy83@gmail.com>
Upstream-commit: cb6633175c0de0a7ae155c4d378cd2379681554b
Component: engine
Adds 2 new methods to v2 plugin `Acquire` and `Release` which allow
refcounting directly at the plugin level instead of just the store.
Since a graphdriver is initialized exactly once, and is really managed
by a separate object, it didn't really seem right to call
`getter.Get()` to refcount graphdriver plugins.
On shutdown it was particularly weird where we'd either need to keep a
driver reference in daemon, or keep a reference to the pluggin getter in
the layer store, and even then still store extra details on if the
graphdriver is a plugin or not.
Instead the plugin proxy itself will handle calling the neccessary
refcounting methods directly on the plugin object.
Also adds a new interface in `plugingetter` to account for these new
functions which are not going to be implemented by v1 plugins.
Changes terms `plugingetter.CREATE` and `plugingetter.REMOVE` to
`ACQUIRE` and `RELEASE` respectively, which seems to be better
adjectives for what we're doing.
Signed-off-by: Brian Goff <cpuguy83@gmail.com>
Upstream-commit: f29bbd16f5d2bb82d815ea59f8ef85fe59384c89
Component: engine
Legacy plugins expect host-relative paths (such as for Volume.Mount).
However, a containerized plugin cannot respond with a host-relative
path. Therefore, this commit modifies new volume plugins' paths in Mount
and List to prepend the container's rootfs path.
This introduces a new PropagatedMount field in the Plugin Config.
When it is set for volume plugins, RootfsPropagation is set to rshared
and the path specified by PropagatedMount is bind-mounted with rshared
prior to launching the container. This is so that the daemon code can
access the paths returned by the plugin from the host mount namespace.
Signed-off-by: Tibor Vass <tibor@docker.com>
Upstream-commit: c54b717caf1a55e525ce180bfcb42addd59c6633
Component: engine
Use GetByName to check for collision before create any context in plugin creation
Upstream-commit: 9d884986f5c001cacb60aa3c50036575ed2dd22d
Component: engine
v2/Plugin struct had fields that were
- purely used by the manager.
- unsafely exposed without proper locking.
This change fixes this, by moving relevant fields to the manager as well
as making remaining fields as private and providing proper accessors for
them.
Signed-off-by: Anusha Ragunathan <anusha@docker.com>
Upstream-commit: b35490a8ba2ad70a585c1ba8109b6d87aece8daa
Component: engine
This fix tries to address the issue raised on 29185 where
`docker inspect <unknown object>` on Windows will return:
```
Error response from daemon: plugins are not supported on this platform
```
The reason was that in case `--type` is not specified, `docker inspect`
will iterate through different types `container`, `image`, `network`,
`plugin` etc. The `plugin` object is the last type to check.
However, as `plugin` is not supported on Windows yet, the error message
is not very informative for `plugins are not supported on this platform`.
This fix tries to fix the issue by return a `not found` error on unsupported
platforms as well.
An integration test has been added to cover the changes for Windows/Linux.
This fix fixes 29185.
Signed-off-by: Yong Tang <yong.tang.github@outlook.com>
Upstream-commit: 88fcdb0a825da040ef2b1f9c191af480f0f2cc90
Component: engine
This fix tries to address the proposal raised in 28946
to support plugins in `docker inspect`.
The command `docker inspect` already supports
"container", "image", "node", "network", "service", "volume", "task".
However, `--type plugin` is not supported yet at the moment.
This fix address this issue by adding the support of `--type plugin`
for `docker inspect`.
An additional integration test has been added to cover the changes.
This fix fixes 28946.
Signed-off-by: Yong Tang <yong.tang.github@outlook.com>
Upstream-commit: 90bb2cdb9f15a9b1b9a4e2ea4242882665daac4e
Component: engine
This fix tries to address the issue raised in discussion of
PR 28735 where it was not possible to manage plugin based on
plugin ID. Previously it was not possible to invoke
`docker plugin inspect` with a plugin ID (or ID prefix).
This fix updates the implementation of `docker plugin inspect`
so that it is possbile to search based on a plugin name, or a
plugin ID. A short format of plugin ID (prefix) is also possible,
as long as there is no ambiguity.
Previously the check of `docker plugin inspect` was mostly done
on the client side. This could potentially cause inconsistency
between API and CMD. This fix move all the checks to daemon side
so that API and CMD will be consistent.
An integration test has been added to cover the changes.
Signed-off-by: Yong Tang <yong.tang.github@outlook.com>
Upstream-commit: 0ce6e070f7d1e4b1b478d52b4464f8480dbfd9b7
Component: engine
This fix is a follow up to the comment:
https://github.com/docker/docker/pull/28717#discussion_r90040589
Currently, the collision checking is done at the last step `Add()` of
plugin creation. However, at this stage the context such as plugin
directories have already been creation. In case of name collision,
rollback is needed which could be expensive.
This fix performs the check at the beginning of CreateFromContext using
GetByName. In this way, collision fails fast and no context creation
or rollback is needed.
Signed-off-by: Yong Tang <yong.tang.github@outlook.com>
Upstream-commit: 52405a9b5896fd1c3ea6d8b1ca1c70e5979e3271
Component: engine
A plugin has an `ExitChan` channel which is used to signal the exit of
the plugin process. In a recent change, the initialization was
incorrectly moved to the daemon Shutdown path.
Fix this by initializing the channel during plugin enable.
Signed-off-by: Anusha Ragunathan <anusha@docker.com>
Upstream-commit: 890a98ceed982454515f5b089d9772fc1e4eb6e0
Component: engine
This fix tries to fix the issue raised in 28684:
1. Duplicate plugin create with the same name will override the old plugin reference
2. In case an error happens in the middle of the plugin creation, plugin directories
in `/var/lib/docker/plugins` are not cleaned up.
This fix update the plugin store so that `Add()` will return an error if a plugin
with the same name already exist.
This fix also will clean up the directory in `/var/lib/docker/plugins` in case
an error happens in the middle of the plugin creation.
This fix fixes 28684.
Signed-off-by: Yong Tang <yong.tang.github@outlook.com>
Upstream-commit: 662d456928e47162a3af5931356cb05b6a3f9918
Component: engine
In the plugin manifest, Capabilities has been moved to
Linux.Capabilities to avoid confusion with Interface.Types[i].Capability
A DeviceCreation boolean has also been added to the manifest. This could
be changed in the future to be specific to a major number.
Signed-off-by: Tibor Vass <tibor@docker.com>
Upstream-commit: 9f239281b1b02ed46f98af1eb39bc9b2165073fa
Component: engine
