1
0
Fork 0
mirror of https://github.com/moby/moby.git synced 2022-11-09 12:21:53 -05:00
Commit graph

12 commits

Author SHA1 Message Date
Brian Goff
7c77df8acc Move plugin client to separate interface
This makes it a bit simpler to remove this interface for v2 plugins
and not break external projects (libnetwork and swarmkit).

Note that before we remove the `Client()` interface from `CompatPlugin`
libnetwork and swarmkit must be updated to explicitly check for the v1
client interface as is done int his PR.

This is just a minor tweak that I realized is needed after trying to
implement the needed changes on libnetwork.

Signed-off-by: Brian Goff <cpuguy83@gmail.com>
2018-05-30 15:22:10 -04:00
Brian Goff
f51a96c016 Move plugin client creation to the extension point
Signed-off-by: Brian Goff <cpuguy83@gmail.com>
2018-05-25 15:18:53 -04:00
Sebastiaan van Stijn
20028325da
Merge pull request #35829 from cpuguy83/no_private_mount_for_plugins
Perform plugin mounts in the runtime
2018-02-21 12:28:13 +01:00
Brian Goff
0e5eaf8ee3 Ensure plugin returns correctly scoped paths
Before this change, volume management was relying on the fact that
everything the plugin mounts is visible on the host within the plugin's
rootfs. In practice this caused some issues with mount leaks, so we
changed the behavior such that mounts are not visible on the plugin's
rootfs, but available outside of it, which breaks volume management.

To fix the issue, allow the plugin to scope the path correctly rather
than assuming that everything is visible in `p.Rootfs`.
In practice this is just scoping the `PropagatedMount` paths to the
correct host path.

Signed-off-by: Brian Goff <cpuguy83@gmail.com>
2018-02-07 15:48:27 -05:00
Daniel Nephin
4f0d95fa6e Add canonical import comment
Signed-off-by: Daniel Nephin <dnephin@docker.com>
2018-02-05 16:51:57 -05:00
Brian Goff
3816b51438 Fixup some issues with plugin refcounting
In some circumstances we were not properly releasing plugin references,
leading to failures in removing a plugin with no way to recover other
than restarting the daemon.

1. If volume create fails (in the driver)
2. If a driver validation fails (should be rare)
3. If trying to get a plugin that does not match the passed in capability

Ideally the test for 1 and 2 would just be a unit test, however the
plugin interfaces are too complicated as `plugingetter` relies on
github.com/pkg/plugin/Client (a concrete type), which will require
spinning up services from within the unit test... it just wouldn't be a
unit test at this point.
I attempted to refactor this a bit, but since both libnetwork and
swarmkit are reliant on `plugingetter` as well, this would not work.
This really requires a re-write of the lower-level plugin management to
decouple these pieces.

Signed-off-by: Brian Goff <cpuguy83@gmail.com>
2017-10-21 15:17:57 -04:00
Aaron Lehmann
428600108c plugingetter: Avoid all caps for constant declarations
Go style calls for mixed caps instead of all caps:
https://golang.org/doc/effective_go.html#mixed-caps

Change LOOKUP, ACQUIRE, and RELEASE to Lookup, Acquire, and Release.

This vendors a fork of libnetwork for now, to deal with a cyclic
dependency issue. The change will be upstream to libnetwork once this is
merged.

Signed-off-by: Aaron Lehmann <aaron.lehmann@docker.com>
2017-01-04 10:19:04 -08:00
Madhu Venugopal
8f1b793528 Add a GetAll function that returns only managed plugins supported by V2
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>
2016-12-22 10:26:04 -08:00
allencloud
7c3657065c change minor mistake of spelling
Signed-off-by: allencloud <allen.sun@daocloud.io>
2016-12-20 21:05:19 +08:00
Brian Goff
f29bbd16f5 Refcount graphdriver plugins properly
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>
2016-12-09 19:46:28 -05:00
Tibor Vass
c54b717caf plugins: container-rootfs-relative paths
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>
2016-12-09 10:16:24 -08:00
Anusha Ragunathan
d599d53db2 Add plugingetter to pkg.
plugingetter is indepedent of docker/docker packages, so it can be
moved to pkg. This is also necessary for authorization plugins (part of
pkg) to use pluginv2. The original path at plugin/getter will be
eventually removed, when external repos (eg. libnetwork) update their
import paths.

Signed-off-by: Anusha Ragunathan <anusha@docker.com>
2016-10-04 12:03:29 -07:00