`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>
Upstream-commit: 21fcbb39b73310e69d6403a1cfa8b26799cc1355
Component: engine
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>
Upstream-commit: 45833ce54d741b2378819e3ba5859533c317ae01
Component: engine
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>
Upstream-commit: 11df2db538fbc7a6181c591b6ec47db9f96a87e4
Component: engine
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>
Upstream-commit: 39bdf601f6bea3c189d8e189e13c7e48b6f66b43
Component: engine
There is still ways to go
Signed-off-by: Vincent Demeester <vincent@sbr.pm>
Upstream-commit: 87e3fcfe1e059780c4ee57abb097296fd29e09af
Component: engine
This fix tries to address the issue raised in 29810
where btrfs subvolume removal failed when docker
is in an unprivileged lxc container. The failure
was caused by `Failed to rescan btrfs quota` with
`operation not permitted`.
However, if disk quota is not enabled, there is no
need to run a btrfs rescan at the first place.
This fix checks for `quotaEnabled` and only run btrfs
rescan if `quotaEnabled` is true.
This fix fixes 29810.
Signed-off-by: Yong Tang <yong.tang.github@outlook.com>
Upstream-commit: b36e613d9f311e69387ccec2be16f8618fa1f558
Component: engine
This fix tries to add a placeholder `.CreatedAt` for Go
format template in `docker network ls --format`.
While working on 29226, I noticed that it is not possible to
display network's creation time in `docker network ls`, with or
without `--format`.
We are able to find the timestamp through `docker network inspect` though.
However, as we allows networks to be pruned based on the timestamp
(see 29226), showing the timestamp in `docker network ls --format`
would be much useful now.
This fix adds the `.CreatedAt` placeholder for `docker network ls --format`.
The default output was not changed for `docker network ls --format`.
A test case for unit tests has been added.
Signed-off-by: Yong Tang <yong.tang.github@outlook.com>
Upstream-commit: 0ad02c610880f7ccb96be418baa8667e41aba7a5
Component: engine
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>
Upstream-commit: 58738cdee327f5de481dcf7d3d377374cbb5f13a
Component: engine
This makes the test a bit more robust to change and is a bit cleaner.
As implemented before this commit, we have two named plugins pointing to
the same http service. If the daemon makes any unexpected calls to the
plugin (e.g. during startup) we'll get more counts on the event counter
than expected since the daemon sees 2 plugins.
Found this while working on #29877 which broke this test originally (but
is no longer using V1 plugins, so is this is no longer broken there) and
took some time to debug what was going on.
Signed-off-by: Brian Goff <cpuguy83@gmail.com>
Upstream-commit: 4bd4d18e1164e1d0b9f22ddd54a88abdf167e8d7
Component: engine
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>
Upstream-commit: 6aaa85f0b0dd030f68512ca9004823926419f5fd
Component: engine
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
Sebastiaan van Stijn
wefine
Harald Albers
yuexiao-wang
Akihiro Suda
Brian Goff
lixiaobing10051267
Tonis Tiigi
Aaron Lehmann
Victor Vieux
Tibor Vass
Josh Eveleth
Vivek Goyal
Vincent Demeester
allencloud
Yong Tang
Yunxiang Huang
John Howard
Madhu Venugopal