Use `testutil/cmd` for `buildCommand`.
Signed-off-by: Vincent Demeester <vincent@sbr.pm>
Upstream-commit: c778f4b964934aeaf0d86d79ea7397940b303238
Component: engine
Docker 1.13 moves the `--rm` flag to the daemon,
through an AutoRemove option in HostConfig.
When using API 1.24 and under, AutoRemove should not be
used, even if the daemon is version 1.13 or above and
"supports" this feature.
This patch fixes a situation where an 1.13 client,
talking to an 1.13 daemon, but using the 1.24 API
version, still set the AutoRemove property.
As a result, both the client _and_ the daemon
were attempting to remove the container, resulting
in an error:
ERRO[0000] error removing container: Error response from daemon:
removal of container ce0976ad22495c7cbe9487752ea32721a282164862db036b2f3377bd07461c3a
is already in progress
In addition, the validation of conflicting options
is moved from `docker run` to `opts.parse()`, so
that conflicting options are also detected when
running `docker create` and `docker start` separately.
To resolve the issue, the `AutoRemove` option is now
always set to `false` both by the client and the
daemon, if API version 1.24 or under is used.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Upstream-commit: 0ea7b143b0a8366799c83a955be676aaf1345214
Component: engine
c54b717 caused a regression for pluginv1 on Windows, where extraneous
backslashes were added to BasePath of the plugin. For pluginv1 on windows,
BasePath() should return an empty string, since the plugin is fully aware
of the mount path. Also, unlike Linux where all paths are relative to "/",
Windows paths are dependent on system drives and mapped drives.
Fixes#30148
Signed-off-by: Anusha Ragunathan <anusha.ragunathan@docker.com>
Upstream-commit: 0ef21eb0e30d2ea036730a7c5502f888c6b763d1
Component: engine
This fix catches the case where there is a single container port
and a dynamic host port and will fail out gracefully
Example docker-compose.yml snippet:
port:
ports:
- "8091-8093:8091"
- "80:8080"
Signed-off-by: Tony Abboud <tdabboud@hotmail.com>
Upstream-commit: 135f8f967488f171fcda6c66d7fa35726edaf19c
Component: engine
Changes a couple of generate scripts so that the architecture
gets the go version from its own Dockerfile. This should cover a
rare case where the go version might have to be different from
the x86 Dockerfile.
Signed-off-by: Christopher Jones <tophj@linux.vnet.ibm.com>
Upstream-commit: fa17ac256019729a15f6c33c2c2dad34acef9e4a
Component: engine
Instead of a timeout the context is cancelled on error to ensure
proper cleanup of the associated fifos' goroutines.
Signed-off-by: Kenfe-Mickael Laventure <mickael.laventure@gmail.com>
Upstream-commit: c178700a0420118fe7f632af4da1bc43abd3a9bf
Component: engine
Issue #30082 demonstrated that their is possible confusion with the "/."
where the tailing "." can appear to be merely punctuation within the
document rather than a highly pertinent part of `SRC_PATH`.
Signed-off-by: Ian Campbell <ian.campbell@docker.com>
Upstream-commit: fca6cda4b0307d1268e684dde65e6a916d729d04
Component: engine
Commit b717de5153db503fae61c11e30f04f400f66a6fd
changed the name of the "size" argument to
"virtualSize", as the "VirtualSize" field
was re-used for calculating the size of all
layers _not_ used by other images.
be20dc15af0cb281bd6d11586cfcc96bd50d12ca reverted
the change in calculation, but did not change
the argument name back to "size".
This changes the name back to its original
name, because since the introduction of the
content-addressable store in docker 1.10,
there no longer is a "virtual" size, so
"size" is a better name for this argument.
Signed-off-by: Sebastiaan van Stijn <github@gone.nl>
Upstream-commit: 22c411517a4a203690edb52fa42f8d5b43252882
Component: engine
If you created containers from pre-OCI docker (e.g. docker-1.10.x)
upgrade may fail when restarting containers if the new docker daemon
has `--default-runtime` set.
In Fedora, we ship docker 1.12.6 with:
```
--default-runtime=oci
--add-runtime oci=/usr/libexec/docker/docker-runc-current
```
That way we don't rely on `docker-runc` being in `$PATH`.
The issue is, on upgrade from docker 1.10.3 without this patch, the
default runtime in `daemon/start_linux.go` is unconditionally set to
`runc=docker-runc` without honoring the `--default-runtime` flag set in
the docker daemon.
Reproducer:
- (1.10.3) `docker run -d -p 5000:5000 --restart=always --name registry
registry:2`
- upgrade to docker 1.12.6 (1.11.x has likely the same issue)
- the registry container fails to restart on upgrade with the following
log message `error="exec: \"docker-runc\": executable file not
found in $PATH: \"\""`
That error comes from the fact that we're setting the runtime in the
container's HostConfig to `runc` where instead we should have honored
the `--default-runtime` flag (in our case that's set to `oci`).
Signed-off-by: Antonio Murdaca <runcom@redhat.com>
Upstream-commit: 9391a822ea4bee60284b4b2eb3a6535e20492569
Component: engine
