We add a --device flag which can be used like:
docker run --device /dev/sda:/dev/xvda:rwm ubuntu /bin/bash
To allow the container to have read write permissions to access the host's /dev/sda via a node named /dev/xvda in the container.
Note: Much of this code was written by Dinesh Subhraveti dineshs@altiscale.com (github: dineshs-altiscale) and so he deserves a ton of credit.
Docker-DCO-1.1-Signed-off-by: Timothy <timothyhobbs@seznam.cz> (github: timthelion)
Upstream-commit: e855c4b92170534864b920ec1e267b3a815764f9
Component: engine
Update bash completion to only complete on directories as the argument to "docker build"
Upstream-commit: 439d7ea701b44724e1e02ff67a220fab7fa9bd1f
Component: engine
Commit 09ee269d ("devmapper: Add option for specifying the thin pool
blocksize") also switched the default dm-thin-pool blocksize from 64K to
512K. That change unfortunately breaks the activation of dm-thin-pool
devices that were previously created using a 64K blocksize. Here is an
example of the dm-thin-pool activation failure users may experience:
device-mapper: thin: 253:4: pool target (204800 blocks) too small: expected 1638400
device-mapper: table: 253:4: thin-pool: preresume failed, error = -22
The reason for this is docker is passing 512K as the blocksize for a
dm-thin-pool that was previously created using a 64K blocksize. Docker
doesn't record the blocksize the is used when it creates a dm-thin-pool.
Until now it never had a need to do so because the blocksize was always
hardcoded. The dm-thin-pool blocksize must be the same every time a
dm-thin-pool is activated.
As a stop-gap fix, revert to using 64K for the default blocksize.
But we do need a proper fix for this now that 'dm.blocksize' is exposed
as a proper storage option. One possible fix would be to record the
blocksize for each dm-thin-pool that docker creates and to pass that
recorded blocksize down in the dmsetup table load each time the
dm-thin-pool is activated (this would be comparable to what lvm2 does).
Docker-DCO-1.1-Signed-off-by: Mike Snitzer <snitzer@redhat.com> (github: snitm)
Upstream-commit: d715803d45d41bfbbd5faf1f4a8239c08d6d8c90
Component: engine
Currently the docker logs timestamp flag generates log entries like:
$ sudo docker logs -ft daemon_dave
[May 10 13:06:17.934] hello world
It uses Go's StampMilli timestamp to generate the timestamp. The entry
is also wrapped in [ ].
This is non-standard operational timestamp and one that will require
custom parsing.
The new timestamp is RFC3999Nano and generates entries like:
2014-05-10T17:42:14.999999999Z07:00 hello world
These are readily parsed by tools like ELK.
Docker-DCO-1.1-Signed-off-by: James Turnbull <james@lovedthanlost.net> (github: jamtur01)
Docker-DCO-1.1-Signed-off-by: Tibor Vass <teabee89@gmail.com> (github: tiborvass)
Upstream-commit: aa0eca03e6662c5f6b4f0f47190a45f49b61e357
Component: engine
Docker-DCO-1.1-Signed-off-by: Samuel Reis <srijs@airpost.net> (github: srijs)
Upstream-commit: 560eb07009d65fbcfb49b2fa8b04a2e3f4d647e8
Component: engine
Docker-DCO-1.1-Signed-off-by: Samuel Reis <srijs@airpost.net> (github: srijs)
Upstream-commit: 46747963b603a5573a0b26dcef407a96757926e7
Component: engine
Revised to match new UI, fixed links, copy edits and improvements.
Docker-DCO-1.1-Signed-off-by: Fred Lifton <fred.lifton@docker.com> (github: fredlf)
More revisions to builds.md
Corrections to automated build process, copy edits.
Docker-DCO-1.1-Signed-off-by: Fred Lifton <fred.lifton@docker.com> (github: fredlf)
Edits based on Sonat's feedback
Docker-DCO-1.1-Signed-off-by: Fred Lifton <fred.lifton@docker.com> (github: fredlf)
Upstream-commit: 27c34f3eb93ee58d585f8b792659dc2c0464bd0d
Component: engine