`plugins.GetAll()` was not locking the plugin map when checking if a
plugin exists, this can cause a race and potentially a panic if another
goroutine is trying to load a plugin into the map at the same time.
Also fixes a race during activation where a plugin inserts itself into
the plugin map but does not check if something else is already there.
This is already checked before trying to activate the plugin, however
the map lock is not held for this entire period, so other plugins may be
loaded during this time.
To fix, before inserting the plugin into the map, check if one with the
same name already exists and use that instead.
Signed-off-by: Brian Goff <cpuguy83@gmail.com>
This test checks for the substring "foo" in the "secret ls" output. This
is a valid base36 substring and can sometimes show up by chance:
docker_cli_secret_create_test.go:86:
c.Assert(out, checker.Not(checker.Contains), name)
... obtained string = "" +
... "ID NAME CREATED UPDATED\n" +
... "ob8y4t4feuz8pn5h6vla9oxoz stefoo7e268ozqfupi9s4se9q Less than a second ago Less than a second ago\n"
... substring string = "foo"
Change the secret name to test_secret, matching other tests. Underscores
can't appear in base36 so this name is safe to grep for.
Signed-off-by: Aaron Lehmann <aaron.lehmann@docker.com>
Vendor the latest official logrus release instead of a custom fork
(which now happens to be identical to the fork).
Signed-off-by: Aaron Lehmann <aaron.lehmann@docker.com>
I often get complains that container removal failed and users got following
error message.
"Driver devicemapper failed to remove root filesystem 18a69ba82aaf7a039ce7d44156215012d703001643079775190ac7dd6c6acf56:Device is Busy"
This error message talks about container id but does not give any info
about which particular device id is busy. Most likely device is mounted
in some other mount namespace and if one knows the device id, they
can try to do some debugging figuring which process and which mount
namespace is keeping the device busy and how did we reach that stage.
Without that information, it becomes almost impossible to debug the
problem.
So to improve the debuggability, when device removal fails, also return
device id in error message. Now new message looks as follows.
"Driver devicemapper failed to remove root filesystem 18a69ba82aaf7a039ce7d44156215012d703001643079775190ac7dd6c6acf56: Failed to remove device dbc15bdf9994a17c613d8ef9e924f3cffbf67f91e4f709295c901ad628377991:Device is Busy"
Signed-off-by: Vivek Goyal <vgoyal@redhat.com>
This fix is a follow up for comment
https://github.com/docker/docker/pull/28535#issuecomment-263215225
This fix provides `--filter until=<timestamp>` for `docker container/image prune`.
This fix adds `--filter until=<timestamp>` to `docker container/image prune`
so that it is possible to specify a timestamp and prune those containers/images
that are earlier than the timestamp.
Related docs has been updated
Several integration tests have been added to cover changes.
This fix fixes#28497.
This fix is related to #28535.
Signed-off-by: Yong Tang <yong.tang.github@outlook.com>
returned in "docker info". Currently info endpoint isnt using the
GetAllByCap, but relies on existing networks to get the plugin names.
This causes a basic issue when it comes to global network plugins which
swarm-mode relies on, wherein swarmkit will not be able to schedule the
network on the worker nodes due to the filtering logic.
In order to break this chicken & egg issue, we must start to use the
GetAllManagedPluginsByCap. We are unable to use GetAllByCap due to
various issues with Plugin-V1's lazy loading approach causing issues
especially during daemon restarts (which uses SystemInfo)
Signed-off-by: Madhu Venugopal <madhu@docker.com>
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>
