daemon cache was getting the whole image map and then iterating through
it to find children. This information is already stored in the image
store.
Prior to this change building the docker repo with a full cache took 30
seconds.
After it takes between 15 seconds or less (As low as 9 seconds).
This is an improvement on docker 1.9.1 which hovered around 17 seconds.
Signed-off-by: Brian Goff <cpuguy83@gmail.com>
Upstream-commit: 1350e8b7b8025d73056b800963c001fb9619a85c
Component: engine
since it is an error if that address is unavailable.
Signed-off-by: Bryan Boreham <bjboreham@gmail.com>
Upstream-commit: 7126ecd0ad1f6188540949cbdbca20f4a75d1839
Component: engine
This removes all references to InitPath and InitSha1, as well as pulling
in a few other minor engine-api fixes.
Signed-off-by: Aleksa Sarai <asarai@suse.com>
Upstream-commit: 71c63aa72e3788af27fef0de9005cde6c7728a2b
Component: engine
User call `Start` could with args, and the args could
contains `--storage-driver`, but in `Start`, it will add
`--storage-driver` even though user has specified `--storage-driver`
in args.
Signed-off-by: Lei Jitang <leijitang@huawei.com>
Upstream-commit: e88258ca2ef0047973168a29fd9ec27669582c0e
Component: engine
While the documentation is very patchy on dockerinit, remove all
references in packaging documentation to the now purged dockerinit.
Signed-off-by: Aleksa Sarai <asarai@suse.com>
Upstream-commit: e72192be404c9a8489191d43fd6e5c429081d5c8
Component: engine
dockerinit has been around for a very long time. It was originally used
as a way for us to do configuration for LXC containers once the
container had started. LXC is no longer supported, and /.dockerinit has
been dead code for quite a while. This removes all code and references
in code to dockerinit.
Signed-off-by: Aleksa Sarai <asarai@suse.com>
Upstream-commit: 4357ed4a7363a1032edf93cf03232953c805184f
Component: engine
https://github.com/docker/libnetwork/pull/810 provides the more complete
solution for moving the Port-mapping ownership away from endpoint and
into Sandbox. But, this PR makes the best use of existing libnetwork
design and get a step closer to the gaol.
Signed-off-by: Madhu Venugopal <madhu@docker.com>
Upstream-commit: e38463b2779f455b4173171d5a1fdb115180a7e9
Component: engine
Currently, the temporary file storing downloaded layer data is only
removed after a successful download or a digest verification error. A
transport-level error does not cause it to be removed. This is a
regression from 1.9 that could cause disk usage to grow until the Docker
daemon is restarted.
Signed-off-by: Aaron Lehmann <aaron.lehmann@docker.com>
Upstream-commit: 5a363ce60bee3dc26a433c7e2cee6dc76939849e
Component: engine
Change the way we install from backports in the deb builder (to force deps too)
Upstream-commit: ced2d37901588f5dc8b94a45bb8686e8fbb943a4
Component: engine
Also, add "libsystemd-journal-dev" to the explicit list (which is what prompted the change in how we install).
Signed-off-by: Andrew "Tianon" Page <admwiggin@gmail.com>
Upstream-commit: 722fac7a730e16c65ccd60ce5d1d7924dd6520bf
Component: engine
- Currently it is being save upfront...
Signed-off-by: Alessandro Boch <aboch@docker.com>
Upstream-commit: 733245b2e7517b88cdfb188f9d8418f29bca6338
Component: engine
Things could go wrong if Watch was called after the last existing
watcher was released. The call to Watch would succeed even though it was
not really adding a watcher, and the corresponding call to Release would
close hasWatchers a second time.
The fix for this is twofold:
1. We allow transfers to gain new watchers after the watcher count has
touched zero. This means that the channel returned by Released should
not be closed until all watchers have been released AND the transfer is
no longer tracked by the transfer manager, meaning it won't be possible
for additional calls to Watch to race with closing the channel returned
by Released.
The Transfer interface has a new method called Close so the transfer can
know when the transfer manager no longer references it.
Remove the Cancel method. It's not used and should not be exported.
2. Even though (1) makes it possible to add watchers after all the
previous watchers have been released, we want to avoid doing this in
practice. A transfer that has had all its watchers released is in the
process of being cancelled, and attaching to one of these will never be
the correct behavior. Add a check if a watcher is attaching to a
cancelled transfer. In this case, wait for the transfer to be removed
from the map and try again. This will ensure correct behavior when a
watcher tries to attach during the race window.
Either (1) or (2) should be sufficient to fix the race involved here,
but the combination is the most correct approach. (1) fixes the
low-level plumbing to be resilient to the race condition, and (2) avoids
using it in a racy way.
Fixes#19606
Signed-off-by: Aaron Lehmann <aaron.lehmann@docker.com>
Upstream-commit: 3e2b50ccaadb5ecbd70bf27adc287973f0417573
Component: engine
