Commit Graph

8 Commits

Author SHA1 Message Date
4cadaa03f8 Update tests to use gotest.tools 👼
Signed-off-by: Vincent Demeester <vincent@sbr.pm>
Upstream-commit: 38457285242e57306c5b7ee652c7ccbb9fbd6713
Component: engine
2018-06-13 09:04:30 +02:00
0331f04e35 Post migration assertion fixes
Signed-off-by: Daniel Nephin <dnephin@docker.com>
Upstream-commit: c9e52bd0da0461e605a3678b85702f83081504a7
Component: engine
2018-03-16 11:03:46 -04:00
60daf5fa97 Automated migration using
gty-migrate-from-testify --ignore-build-tags

Signed-off-by: Daniel Nephin <dnephin@docker.com>
Upstream-commit: 6be0f709830113966f295401327b027ec2f0bbca
Component: engine
2018-03-16 11:03:43 -04:00
be83c11fb0 Add canonical import comment
Signed-off-by: Daniel Nephin <dnephin@docker.com>
Upstream-commit: 4f0d95fa6ee7f865597c03b9e63702cdcb0f7067
Component: engine
2018-02-05 16:51:57 -05:00
6347d30b6f Fix issue with plugin scanner going to deep
The plugin spec says that plugins can live in one of:

- /var/run/docker/plugins/<name>.sock
- /var/run/docker/plugins/<name>/<name>.sock
- /etc/docker/plugins/<name>.[json,spec]
- /etc/docker/plugins/<name>/<name>.<json,spec>
- /usr/lib/docker/plugins/<name>.<json,spec>
- /usr/lib/docker/plugins/<name>/<name>.<json,spec>

However, the plugin scanner which is used by the volume list API was
doing `filepath.Walk`, which will walk the entire tree for each of the
supported paths.
This means that even v2 plugins in
`/var/run/docker/plugins/<id>/<name>.sock` were being detected as a v1
plugin.
When the v1 plugin loader tried to load such a plugin it would log an
error that it couldn't find it because it doesn't match one of the
supported patterns... e.g. when in a subdir, the subdir name must match
the plugin name for the socket.

There is no behavior change as the error is only on the `Scan()` call,
which is passing names to the plugin registry when someone calls the
volume list API.

Signed-off-by: Brian Goff <cpuguy83@gmail.com>
Upstream-commit: b27f70d45a0fbb744c17dda02f597ffa6a47d4d9
Component: engine
2018-02-02 16:49:14 -05:00
dd21307557 Increase the Coverage of pkg/plugins
Increases the test coverage of pkg/plugins.
Changed signature of function NewClientWithTimeout in pkg/plugin/client, to
take time.Duration instead of integers.

Signed-off-by: Raja Sami <raja.sami@tenpearl.com>
Upstream-commit: 8dd100a2297a34a0aef422383117fb0c3314fba1
Component: engine
2017-06-12 12:23:10 +05:00
4defdd0e1e Fix deadlock on v1 plugin with activate error
When a plugin has an activation error, it was not being checked in the
`waitActive` loop. This means it will just wait forever for a manifest
to be populated even though it may never come.

Signed-off-by: Brian Goff <cpuguy83@gmail.com>
Upstream-commit: f2d384fca6fa08da13fdc01c7991e8e35b081198
Component: engine
2017-01-24 11:08:13 -05:00
6b571eeb83 Fix race/deadlock in v1 plugin handlers
When a plugin is activated, and then `plugins.Handle` is called to
register a new handler for a given plugin type, a deadlock occurs when
for anything which calls `waitActive`, including `Get`, and `GetAll`.

This happens because `Handle()` is setting `activated` to `false` to
ensure that plugin handlers are run on next activation.
Maybe these handlers should be called immediately for any plugins which
are already registered... but to preserve the existing behavior while
fixing the deadlock, track if handlers have been run on plugins and
reset when a new handler is registered.

The simplest way to reproduce the deadlock with Docker is to add a `-v
/foo` to the test container created for the external graphdriver tests.

Signed-off-by: Brian Goff <cpuguy83@gmail.com>
Upstream-commit: 2938dce794be7559ba73b4e9630015020a7fa937
Component: engine
2016-12-27 12:27:41 -05:00