Naivediff fails when layers are created directly on top of
each other. Other graphdrivers which use naivediff already
skip these tests. Until naivediff is fixed, skip with overlay2
when running tests on a kernel which causes naivediff fallback.
Fix applydiff to never use the naivediff size when not applying
changes with naivediff.
Signed-off-by: Derek McGowan <derek@mcgstyle.net> (github: dmcgowan)
Upstream-commit: 5a1b557281204964f37e81cb0776758360029555
Component: engine
- when advertise-addr is not local and listen-addr is
not specified
Signed-off-by: Alessandro Boch <aboch@docker.com>
Upstream-commit: c8d0cb9e716585f33dc730911332adbbc458513a
Component: engine
This change incorporates feedback from @thaJeztah in the PR that added
the autolock flag. It changes the descriptions to be different for
"swarm init" and "swarm update" so that the boolean nature so that the
purpose of the flag in both contexts is clearer.
Signed-off-by: Aaron Lehmann <aaron.lehmann@docker.com>
Upstream-commit: 41b84e0994f9ec72990b7f0fc758f602f6241bc6
Component: engine
Plumbed the executor to the container logs backend.
Signed-off-by: Andrea Luzzardi <aluzzardi@gmail.com>
Upstream-commit: 0ec68657139f029e2740780a58e0019df0e42b6a
Component: engine
This is a temporary version for building
Fedora 25. Fedora 25 will be released during
code-freeze, and is currently in beta, so no
official images are available yet.
Current release date is scheduled for 2016-11-15
https://fedoraproject.org/wiki/Releases/25/Schedule
Once released, the image will be updated for
GA
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Upstream-commit: c4f1cb779179b6145702174614706c462a5ceaae
Component: engine
Fixes#22564
When an error occurs on mount, there should not be any call later to
unmount. This can throw off refcounting in the underlying driver
unexpectedly.
Consider these two cases:
```
$ docker run -v foo:/bar busybox true
```
```
$ docker run -v foo:/bar -w /foo busybox true
```
In the first case, if mounting `foo` fails, the volume driver will not
get a call to unmount (this is the incorrect behavior).
In the second case, the volume driver will not get a call to unmount
(correct behavior).
This occurs because in the first case, `/bar` does not exist in the
container, and as such there is no call to `volume.Mount()` during the
`create` phase. It will error out during the `start` phase.
In the second case `/bar` is created before dealing with the volume
because of the `-w`. Because of this, when the volume is being setup
docker will try to copy the image path contents in the volume, in which
case it will attempt to mount the volume and fail. This happens during
the `create` phase. This makes it so the container will not be created
(or at least fully created) and the user gets the error on `create`
instead of `start`. The error handling is different in these two phases.
Changed to only send `unmount` if the volume is mounted.
While investigating the cause of the reported issue I found some odd
behavior in unmount calls so I've cleaned those up a bit here as well.
Signed-off-by: Brian Goff <cpuguy83@gmail.com>
Upstream-commit: 9a2d0bc3adc0c21c82cd1974be45ea0449f9f224
Component: engine
Changes to docs/reference/api/docker_remote_api_v1.25.md up to
and including 2d4203222574623b10d94817b9959a08698f516b
Signed-off-by: Ben Firshman <ben@firshman.co.uk>
Upstream-commit: 48af987afe15a6bc3528a45b36c79448abbc8836
Component: engine
