Commit Graph

11 Commits

Author SHA1 Message Date
8b3646ee75 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>
Upstream-commit: 428600108cce0a11e65ec4ebd9e439e947b55da7
Component: engine
2017-01-04 10:19:04 -08:00
38849b2667 Moves graphdriver plugn docs out of experimental
Also updates some of the structures being sent so plugins are getting
all the new options.

Signed-off-by: Brian Goff <cpuguy83@gmail.com>
Upstream-commit: 677fa03654886ee776ff478c30681d5376cfc196
Component: engine
2016-12-22 15:30:25 -05:00
b70f98ab3e Make graphdriver plugin use plugin BasePath
Also enables `PropagatedMount` for graphdrivers.

Signed-off-by: Brian Goff <cpuguy83@gmail.com>
Upstream-commit: 500210475f6d841b2eacb42fb495e90108db2733
Component: engine
2016-12-15 16:22:13 -05:00
6dcc37964b 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>
Upstream-commit: f29bbd16f5d2bb82d815ea59f8ef85fe59384c89
Component: engine
2016-12-09 19:46:28 -05:00
33ea65e4f5 Allow graphdriver plugins to use v2
Currently the plugin initialization is too late for a loaded v2 plugin
to be usable as a graph driver.

This moves the initialization up before we create the graph driver.

Signed-off-by: Brian Goff <cpuguy83@gmail.com>
Upstream-commit: 020b051dfb92edcb1e43cee77c881dd3e15481c0
Component: engine
2016-11-18 17:23:59 -05:00
9a299b360f Make experimental a runtime flag
Signed-off-by: Kenfe-Mickael Laventure <mickael.laventure@gmail.com>
Upstream-commit: 7781a1bf0fef748877326632b88e92fbf3c90daa
Component: engine
2016-10-24 15:20:01 -07:00
effa6f4094 Update plugingetter import path in docker/docker.
Signed-off-by: Anusha Ragunathan <anusha@docker.com>
Upstream-commit: a98be0344b24d71235c17a87ff425f3d602e48e8
Component: engine
2016-10-11 11:24:18 -07:00
f07146ebf8 Make graphdrivers work with pluginv2.
As part of making graphdrivers support pluginv2, a PluginGetter
interface was necessary for cleaner separation and avoiding import
cycles.

This commit creates a PluginGetter interface and makes pluginStore
implement it. Then the pluginStore object is created in the daemon
(rather than by the plugin manager) and passed to plugin init as
well as to the different subsystems (eg. graphdrivers, volumedrivers).
A side effect of this change was that some code was moved out of
experimental. This is good, since plugin support will be stable soon.

Signed-off-by: Anusha Ragunathan <anusha@docker.com>
Upstream-commit: fefea805e930a67fb6327f8e59415932861358cb
Component: engine
2016-09-20 08:49:48 -07:00
848e510213 plugins: experimental support for new plugin management
This patch introduces a new experimental engine-level plugin management
with a new API and command line. Plugins can be distributed via a Docker
registry, and their lifecycle is managed by the engine.
This makes plugins a first-class construct.

For more background, have a look at issue #20363.

Documentation is in a separate commit. If you want to understand how the
new plugin system works, you can start by reading the documentation.

Note: backwards compatibility with existing plugins is maintained,
albeit they won't benefit from the advantages of the new system.

Signed-off-by: Tibor Vass <tibor@docker.com>
Signed-off-by: Anusha Ragunathan <anusha@docker.com>
Upstream-commit: f37117045c5398fd3dca8016ea8ca0cb47e7312b
Component: engine
2016-06-14 14:20:27 -07:00
e105a29374 Update daemon and docker core to use new content addressable storage
Add distribution package for managing pulls and pushes. This is based on
the old code in the graph package, with major changes to work with the
new image/layer model.

Add v1 migration code.

Update registry, api/*, and daemon packages to use the reference
package's types where applicable.

Update daemon package to use image/layer/tag stores instead of the graph
package

Signed-off-by: Aaron Lehmann <aaron.lehmann@docker.com>
Signed-off-by: Tonis Tiigi <tonistiigi@gmail.com>
Upstream-commit: 4352da7803d182a6013a5238ce20a7c749db979a
Component: engine
2015-11-24 09:40:25 -08:00
b24dbb9a0e Create extpoint for graphdrivers
Allows people to create out-of-process graphdrivers that can be used
with Docker.

Extensions must be started before Docker otherwise Docker will fail to
start.

Signed-off-by: Brian Goff <cpuguy83@gmail.com>
Upstream-commit: b78e4216a2a97704b664da34d526da1f7e080849
Component: engine
2015-09-09 20:24:35 -04:00