Running parseVolumesFromSpec on all VolumesFrom specs before initialize
any mounts endures that we don't leave container.Volumes in an
inconsistent (partially initialized) if one of out mount groups is not
available (e.g. the container we're trying to mount from does not
exist).
Keeping container.Volumes in a consistent state ensures that next time
we Start() the container, it'll run prepareVolumes() again.
The attached test demonstrates that when a container fails to start due
to a missing container specified in VolumesFrom, it "remembers" a Volume
that worked.
Fixes: #8726
Signed-off-by: Thomas Orozco <thomas@orozco.fr>
Conflicts:
integration-cli/docker_cli_start_test.go
cli integration test
Upstream-commit: 967f80f3cceb96f85a4795d42eeb7b84ae0ce24a
Component: engine
`${SOME_VAR%pattern}` was turning into `SOME_VAL%pattern}` which the shell would then balk at.
I've updated the `TOKEN_ENV_INTERPOLATION` regex to account for this (ie, if `${` is used, it _must_ also match the closing `}`), and renamed the variable to not be exported (since it's not used outside the function following it).
I also added comments for the bits of `tokenEnvInterpolation` so they're easier to follow. 😄
Signed-off-by: Andrew Page <admwiggin@gmail.com>
Upstream-commit: 24189b2c36985f8345691fa6ec2c0766cfc133a7
Component: engine
Stable IPs causes some regressions in the way people use Docker, see GH#8493.
Reverting it for 1.3, we'll enable it back for the next release.
Signed-off-by: Andrea Luzzardi <aluzzardi@gmail.com>
Upstream-commit: 5b8379a4349105eb387a4b9836bbd1d83ebe6928
Component: engine
When a container is restarted all the volume configs are parsed again.
Even if the volume was already handled in a previous start it was still
calling "FindOrCreateVolume" on the volume repo causing a new volume to
be created.
This wasn't being detected because as part of the mount initialization
it checks to see if the the _mount_ was already initialized, but this
happens after the parsing of the configs.
So a check is added during parsing to skip a volume which was already
created for that container.
Signed-off-by: Brian Goff <cpuguy83@gmail.com>
Upstream-commit: c985302c5c2fb6d922acf29106b550cb36faaab6
Component: engine
Volume refs were not being restored on daemon restart.
This made it possible to remove a volume being used by other containers
after a daemon restart.
Signed-off-by: Brian Goff <cpuguy83@gmail.com>
Upstream-commit: 9acf7c765c7e074f6c75eaf162ca06ecfe40d692
Component: engine
When stdout/stderr is closed prematurely, the proxy's writes to stdout/stderr
(i.e. `log.Errorf/log.Printf`) will returns with EPIPE error, and go runtime
will terminate the proxy when stdout/stderr writes trigger 10 EPIPE errors.
instead of using stdout/stderr as the status handler, we pass an extra file to
the child process and write `0\n` or `1\nerror message` to it and close it
after. This allow the child process to handle stdout/stderr as normal.
Docker-DCO-1.1-Signed-off-by: Daniel, Dao Quang Minh <dqminh89@gmail.com> (github: dqminh)
Upstream-commit: 3b9d88210e763bebdfd7badb6ed3fd507d0f6513
Component: engine
Prior to the volumes re-factor, data was not being copied on
volumes-from or host-mounted volumes.
After the re-factor, data was being copied for volumes-from.
This reverts this unintentional change in behavior.
Signed-off-by: Brian Goff <cpuguy83@gmail.com>
Upstream-commit: e95b6fb648ab6301b556192a9730a843fab7209f
Component: engine
Needed to check if the mode was invalid and return error, not valid and
return error.
This didn't get picked up because the existing integration-cli tests
were all either expecting errors when a valid mode was passed in (e.g.
"ro" passed in, we expected an error because it was testing write). So
modified a test which was testing for "rw" to actually pass in "rw"
instead of assuming the "rw"
Docker-DCO-1.1-Signed-off-by: Brian Goff <bgoff@cpuguy83-mbp.home> (github: cpuguy83)
Upstream-commit: 007b4f63409c6c642fb075640a8ec7d58825edc8
Component: engine
This change will allocate network settings (IP and public ports) at
container creation rather than start and keep them throughout the
lifetime of the container (i.e. until it gets destroyed) instead of
discarding them when the container is stopped.
Signed-off-by: Andrea Luzzardi <aluzzardi@gmail.com>
Upstream-commit: a4875937293f3b0a8ffc569608bbca40a456e9c8
Component: engine
Now that the archive package does not depend on any docker-specific
packages, only those in pkg and vendor, it can be safely moved into pkg.
Signed-off-by: Rafe Colton <rafael.colton@gmail.com>
Upstream-commit: 30d5a42c1f24e26f681b7330249f04fec891aee9
Component: engine
This new version makes sure that the same context is used for the two
builds run in the test. If you don't use the same build then about 1/2 the
time the file copied into the container will look like a different file,
probably due to timestamp differences. But reusing the same context we
re-use the same file on disk and therefore avoid the change in timestamps,
and we use the cache on the 2nd build.
Signed-off-by: Doug Davis <dug@us.ibm.com>
Upstream-commit: 8b3fbac15c0579c1372f3e13f607c1001d149d16
Component: engine
