User may still enable discards by setting dm.blkdiscard=true
Docker-DCO-1.1-Signed-off-by: Mike Snitzer <snitzer@redhat.com> (github: snitm)
Upstream-commit: e49567ba729001c31fe71e4b715eed8f50d7ded9
Component: engine
Ideally lvm2 would be used to create/manage the thin-pool volume that is
then handed to docker to exclusively create/manage the thin and thin
snapshot volumes needed for it's containers. Managing the thin-pool
outside of docker makes for the most feature-rich method of having
docker utilize device mapper thin provisioning as the backing storage
for docker's containers. lvm2-based thin-pool management feature
highlights include: automatic or interactive thin-pool resize support,
dynamically change thin-pool features, automatic thinp metadata checking
when lvm2 activates the thin-pool, etc.
Docker will not activate/deactivate the specified thin-pool device but
it will exclusively manage/create thin and thin snapshot volumes in it.
Docker will not take ownership of the specified thin-pool device unless
it has 0 data blocks used and a transaction id of 0. This should help
guard against using a thin-pool that is already in use.
Also fix typos in setupBaseImage() relative to the thin volume type of
the base image.
Docker-DCO-1.1-Signed-off-by: Mike Snitzer <snitzer@redhat.com> (github: snitm)
Upstream-commit: 2b10749cdd0939e4b9e6e18e160984129d733663
Component: engine
Otherwise udev can unecessarily execute various rules (and issue
scanning IO, etc) against the thin-pool -- which can never be a
top-level device.
Docker-DCO-1.1-Signed-off-by: Mike Snitzer <snitzer@redhat.com> (github: snitm)
Upstream-commit: ad6467f9e17205fa76a3b916efe51ba5c1b37506
Component: engine
Took care of some review comments from crosbymichael.
v2:
- Return "err = nil" if file deviceset-metadata file does not exist.
- Use json.Decoder() interface for loading deviceset metadata.
v3:
- Reverted back to json marshal interface in loadDeviceSetMetaData().
Signed-off-by: Vivek Goyal <vgoyal@redhat.com>
Upstream-commit: 15c74bebc1ea2d51612b5809b4477551547a8b3d
Component: engine
Found by Michael Voznesensky <voznesenskym@gmail.com>
Signed-off-by: Doug Davis <dug@us.ibm.com>
Upstream-commit: 814bc06d7bf69c7775b775179c7a3edb8d30685c
Component: engine
I noticed a few things that were bugging me in the output
of the integration-cli tests.
- one of the tests used println to stdout so we had garage sent to the screen
- some of the test, in their final log message, didn't include the name of
the group/file e.g. daemon - run,iptables was just run,iptables
And yes, I noticed this because I'm anal :-) but also because we should keep
the output of the tests as clean as possible so its easy to spot it when
things go bad.
Signed-off-by: Doug Davis <dug@us.ibm.com>
Upstream-commit: 0cef21cfba5b06ce7bd5d6b68865a9df0aca95fc
Component: engine
The Docker Governance Advisory Board (DGAB) met for the first time Tue 10/21/2014.
Among other topics, the DGAB reviewed and refreshed the Docker Project Statement of Direction.
(Sven added from the Pull Req #9055)
Docker-DCO-1.1-Signed-off-by: Scott Johnston <scott.johnston@docker.com> (github: j0hnst0n)
Signed-off-by: Sven Dowideit <SvenDowideit@home.org.au>
Upstream-commit: d94de133f4900509821cafb5208d91443119f809
Component: engine
Current implementation is hard to reason about because of trying to mix
unix/tcp server implementations, even though they are quite different.
This cleans that up.
Also makes it possible to create and manage a new API server easily,
e.g. for adding an introspection socket to a container.
Built in such a way as to allow a non-HTTP server to work as well, such
as libchan.
Signed-off-by: Brian Goff <cpuguy83@gmail.com>
Upstream-commit: dacae746b70f50dd1f3ea9d40834386b96b6c200
Component: engine
Use the HTTP Last-Modified http header as the mtime value for ADD cmd when present
Upstream-commit: 4fcd3dd7488ba779c48557e90598c81c94bf74e4
Component: engine
Linking to the docs readme to help would-be contributors discover the style guide and docs contribution guidelines.
Docker-DCO-1.1-Signed-off-by: Fred Lifton <fred.lifton@docker.com> (github: fredlf)
Upstream-commit: 67ca7415e71a3e6389b883f746a1a15580deb892
Component: engine
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>
Upstream-commit: fb62e184412b6d2bf38975a7051738f05b1f413d
Component: engine
