Update for changes in docker 1.2. Running the docker daemon with "-r=false" has been deprecated in favor of per-container restart policies.
Signed-off-by: wilsaj <wilson.andrew.j+github@gmail.com>
Upstream-commit: 9542ea72188614d5b14f9e7fc31c80e6425738c4
Component: engine
PR 6720 introduce that use `--dns-search=.` will not set `search` in `/etc/resolv.conf`.
Signed-off-by: Huayi Zhang <irachex@gmail.com>
Upstream-commit: 36ffbd7acf60d15942c0591bb4fec498f021331e
Component: engine
If we need to raise an error, make sure the internal state is clean, because
a successful driver.Get() may have its internal state changed (eg. counting,
or mounts), while callers will only do that after a succussful Mount().
Signed-off-by: shuai-z <zs.broccoli@gmail.com>
Upstream-commit: 05ff40b07a5857b41e17290e1d7cef516f122d6c
Component: engine
Includes changes to mkdocs yml and removes style info from docs Read Me, adding a link instead.
Docker-DCO-1.1-Signed-off-by: Fred Lifton <fred.lifton@docker.com> (github: fredlf)
Conflicts:
docs/README.md
Revisions to style guide based on review.
Docker-DCO-1.1-Signed-off-by: Fred Lifton <fred.lifton@docker.com> (github: fredlf)
More Style Guide revisions based on review.
Docker-DCO-1.1-Signed-off-by: Fred Lifton <fred.lifton@docker.com> (github: fredlf)
A few more style guide copy edits
Docker-DCO-1.1-Signed-off-by: Fred Lifton <fred.lifton@docker.com> (github: fredlf)
Upstream-commit: 461d33eeb0fe1058c9fcea39124c2d1f9e141765
Component: engine
By default is a demo of file differences, but can be used to create a
tar of changes between an old and new path.
Signed-off-by: Vincent Batts <vbatts@redhat.com>
Signed-off-by: Vincent Batts <vbatts@hashbangbash.com>
Upstream-commit: f710a8d7746df5f54e2cbe7b90885e4eb75920b4
Component: engine
* integration test for preserving hardlinks
Signed-off-by: Vincent Batts <vbatts@redhat.com>
Signed-off-by: Vincent Batts <vbatts@hashbangbash.com>
Upstream-commit: f9f80443638fc2d703ee6205c8ef3db8e38db9a3
Component: engine
In an effort to make layer content 'stable' between import
and export from two different graph drivers, we must resolve
an issue where AUFS produces metadata files in its layers
which other drivers explicitly ignore when importing.
The issue presents itself like this:
- Generate a layer using AUFS
- On commit of that container, the new stored layer contains
AUFS metadata files/dirs. The stored layer content has some
tarsum value: '1234567'
- `docker save` that image to a USB drive and `docker load`
into another docker engine instance which uses another
graph driver, say 'btrfs'
- On load, this graph driver explicitly ignores any AUFS metadata
that it encounters. The stored layer content now has some
different tarsum value: 'abcdefg'.
The only (apparent) useful aufs metadata to keep are the psuedo link
files located at `/.wh..wh.plink/`. Thes files hold information at the
RW layer about hard linked files between this layer and another layer.
The other graph drivers make sure to copy up these psuedo linked files
but I've tested out a few different situations and it seems that this
is unnecessary (In my test, AUFS already copies up the other hard linked
files to the RW layer).
This changeset adds explicit exclusion of the AUFS metadata files and
directories (NOTE: not the whiteout files!) on commit of a container
using the AUFS storage driver.
Also included is a change to the archive package. It now explicitly
ignores the root directory from being included in the resulting tar archive
for 2 reasons: 1) it's unnecessary. 2) It's another difference between
what other graph drivers produce when exporting a layer to a tar archive.
Docker-DCO-1.1-Signed-off-by: Josh Hawn <josh.hawn@docker.com> (github: jlhawn)
Upstream-commit: 0d97e082c3b849a6901992e653b8963e8ef10f54
Component: engine
This backend uses the overlayfs union filesystem for containers
plus hard link file sharing for images.
Each container/image can have a "root" subdirectory which is a plain
filesystem hierarchy, or they can use overlayfs.
If they use overlayfs there is a "upper" directory and a "lower-id"
file, as well as "merged" and "work" directories. The "upper"
directory has the upper layer of the overlay, and "lower-id" contains
the id of the parent whose "root" directory shall be used as the lower
layer in the overlay. The overlay itself is mounted in the "merged"
directory, and the "work" dir is needed for overlayfs to work.
When a overlay layer is created there are two cases, either the
parent has a "root" dir, then we start out with a empty "upper"
directory overlaid on the parents root. This is typically the
case with the init layer of a container which is based on an image.
If there is no "root" in the parent, we inherit the lower-id from
the parent and start by making a copy if the parents "upper" dir.
This is typically the case for a container layer which copies
its parent -init upper layer.
Additionally we also have a custom implementation of ApplyLayer
which makes a recursive copy of the parent "root" layer using
hardlinks to share file data, and then applies the layer on top
of that. This means all chile images share file (but not directory)
data with the parent.
Docker-DCO-1.1-Signed-off-by: Alexander Larsson <alexl@redhat.com> (github: alexlarsson)
Upstream-commit: 453552c8384929d8ae04dcf1c6954435c0111da0
Component: engine
builder: Restore /bin/sh handling in CMD when entrypoint is specified with JSON
Upstream-commit: 55702ae3d6f0d09efc466134e62be909fd38d777
Component: engine