Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

Bind mount implementation and tests #602

Merged
merged 4 commits into from Jun 26, 2013

Conversation

Projects
None yet

gabrtv commented May 14, 2013

Despite the well-intentioned reluctance to this feature expressed in #111, being able to mount host directories on containers is critical for many use cases. I've completed a naive implementation (with tests). I hope we can get something like this in master soon!

Usage is as follows:

docker run -b /host base ls /host                     # mounts /host through to the container
docker run -b /host:/container base ls /container     # mounts /host to /container
docker run -b /host:/container:ro base ls /container  # mounts /host to /container in read-only mode

The bind mounts default to read-write but also support read-only mode. I worked this out by modifying lxc.mount.entry manually and working backwards. Given my unfamiliarity with the code-base, this should get close review before being merged.

flaub commented May 16, 2013

+1

Contributor

unclejack commented May 19, 2013

There were some objections concerning how this feature works. I've written an article to document some needs concerning an alternative way to do this and a few things which would improve volumes to make them more useful when used during development and and when used in production:
Volumes & persistent data storage

@ghost ghost assigned shykes and creack May 24, 2013

Collaborator

shykes commented May 30, 2013

From an UI standpoint, I'm happy to merge this, except I would like to force /foo:/bar instead of allowing /foo, to make the workflow less host-specific.

Contributor

unclejack commented May 31, 2013

@shykes Are you saying that you'd like /foo:/bar to work like the volumes? If so, we could save these bind mounts to the config of the image / container and reuse them.

I'm not sure whether this PR could be moved to be merged into a new branch so that it could be developed further there. Of course, it'd also be possible to merge it into master and develop it further in a feature branch.

Collaborator

shykes commented May 31, 2013

I would prefer not saving a host path in the container config, because that would break the portability of the container ("ok, before you run this, make sure you create a directory in your host with the following structure...")

PRs can be updated by simply pushing to the same branch.

@solomonstre
@getdocker

On Fri, May 31, 2013 at 12:19 AM, unclejack notifications@github.com
wrote:

@shykes Are you saying that you'd like /foo:/bar to work like the volumes? If so, we could save these bind mounts to the config of the image / container and reuse them.

I'm not sure whether this PR could be moved to be merged into a new branch so that it could be developed further there. Of course, it'd also be possible to merge it into master and develop it further in a feature branch.

Reply to this email directly or view it on GitHub:
dotcloud#602 (comment)

@shykes @gabrtv @unclejack is anyone actively working on this? Would love to see this in the next release ❤️

Contributor

heavenlyhash commented Jun 2, 2013

Obligatory +1. Docker is gorgeous and I want to all-the-things with it, but this ticket and its predecessors are absolute blockers for me.

Breaking container portability a bit with external mounts is an acceptable tradeoff, I think. If I'm using this feature to keep a database on fast media for example, I don't necessarily expect the semantics of the process in the container to survive without that data anyway. As long as the container can either make it through docker run myimage /bin/bash, or give me an error messages telling me which directories it expects, I'm happy. (The former behavior could involve just mounting an unwritable empty filesystem in the container if it can't find the desired paths outside the container, perhaps?)

Yes, don't worry I want to get this in :) As soon as 0.4 is out the door with build and remote api, this comes next.

@solomonstre
@getdocker

On Sun, Jun 2, 2013 at 1:28 PM, heavenlyhash notifications@github.com
wrote:

Obligatory +1. Docker is gorgeous and I want to all-the-things with it, but this ticket and its predecessors are absolute blockers for me.

Breaking container portability a bit with external mounts is an acceptable tradeoff, I think. If I'm using this feature to keep a database on fast media for example, I don't necessarily expect the semantics of the process in the container to survive without that data anyway. As long as the container can either make it through docker run myimage /bin/bash, or give me an error messages telling me which directories it expects, I'm happy. (The former behavior could involve just mounting an unwritable empty filesystem in the container if it can't find the desired paths outside the container, perhaps?)

Reply to this email directly or view it on GitHub:
dotcloud#602 (comment)

pasky commented Jun 2, 2013

Just to chime in with our usecase: we use docker for self-contained
software that we need to provide with input files and extract output
files from it - workarounds like network transfer are possible, but
much slower and rather complicated.

(Also, if one of your examples is running Firefox in a container,
wouldn't it be nice if you could download files in your Firefox and
then do something else with them on the host machine?)

I'm glad for @shykes's positive stance to this; we are using a
custom-built docker with this patch for the time being.

As someone wiser than me once said: in software, no is temporary, yes is forever. When in doubt, say no, because you can change your mind later :)

@solomonstre
@getdocker

On Sun, Jun 2, 2013 at 2:28 PM, Petr Baudis notifications@github.com
wrote:

Just to chime in with our usecase: we use docker for self-contained
software that we need to provide with input files and extract output
files from it - workarounds like network transfer are possible, but
much slower and rather complicated.
(Also, if one of your examples is running Firefox in a container,
wouldn't it be nice if you could download files in your Firefox and
then do something else with them on the host machine?)
I'm glad for @shykes's positive stance to this; we are using a

custom-built docker with this patch for the time being.

Reply to this email directly or view it on GitHub:
dotcloud#602 (comment)

Just playing around with this patch, as mounting an external location is important enough to me to try it without waiting for docker 0.5

Thought I'd share this note if anyone else decides to give it a spin.

You need to ensure the mount inside the container exists or else you'll get cryptic error.

For example if you execute

docker run -b /dir1/dir2 

The directory /dir1/dir2 must already exist in the container or else you'll receive

failed to mount '/dir1/dir2' on '/usr/lib/lxc/root//dir1/dir2'
lxc-start: failed to setup the mount entries for '24920f312c543a2cef6c76ab4fac7ae45345a54d938e3c0418ea71900a4dd42b'
lxc-start: failed to setup the container
lxc-start: invalid sequence number 1. expected 2
lxc-start: failed to spawn '24920f312c543a2cef6c76ab4fac7ae45345a54d938e3c0418ea71900a4dd42b'

It would be nice if the final versino of this feature was smart enough to create the mount points inside the container if they are missing.

gabrtv commented Jun 4, 2013

Glad to see this bumped in priority! I'm happy to continue working it. It sounds like there are four things we should be addressing:

  1. Force explicit source and destination arguments (e.g. /foo:/bar)
  2. Improve error handling around missing paths (both source and dest)
  3. Update the tests accordingly
  4. Add documentation

Let me know if you'd like me to continue on this, or you'd rather one of the core devs handle it. @shykes @unclejack

Contributor

unclejack commented Jun 4, 2013

@gabrtv Please feel free to continue working on this. I've written above something about exploring other options concerning this PR in case you weren't interested in developing it further, but I'm happy to see that's not the case.

The list of changes you've proposed is reasonable.

We can also discuss on IRC if you need some input or just need to talk about something.

gabrtv commented Jun 4, 2013

@unclejack Sorry I've been incommunicado on the PR.. just got back from a trip abroad without Internet access (wipes brow). I hope to get back to this later this week after I catch up on vacation backlog.

gabrtv commented Jun 6, 2013

@unclejack I've cleaned up the PR as follows:

  • Merged current master (0.4.0+)
  • Now forcing /foo:/bar per @shykes request above
  • Added a comment and fixed newlines in the LXC template
  • Clarified usage in run docs

With regard to error handling on missing host/container directories, I find the errors produced by lxc-start to be sufficient, but I'll let others be the judge..

Missing host directory:

$ docker run -b /missing:/tmp -t -i lucid64 bash
lxc-start: No such file or directory - failed to mount '/missing' on '/usr/lib/lxc/root//tmp'
lxc-start: failed to setup the mount entries for '365878af00f71ee024692755c43a94d39c7bc7a0905186d9668f93897d564399'
lxc-start: failed to setup the container
lxc-start: invalid sequence number 1. expected 2
lxc-start: failed to spawn '365878af00f71ee024692755c43a94d39c7bc7a0905186d9668f93897d564399'

Missing container directory:

$ docker run -b /tmp:/missing -t -i lucid64 bash
lxc-start: No such file or directory - failed to mount '/tmp' on '/usr/lib/lxc/root//missing'
lxc-start: failed to setup the mount entries for 'ddb1888e82f3a7672f365123e67559bca4b707afe2ca7e06da36ee8cfb24c75b'
lxc-start: failed to setup the container
lxc-start: invalid sequence number 1. expected 2
lxc-start: failed to spawn 'ddb1888e82f3a7672f365123e67559bca4b707afe2ca7e06da36ee8cfb24c75b'

It's important to note running the container in daemon mode (-d) swallows the error:

$ docker run -b /tmp:/missing -d lucid64 sleep 60
193bab2528b4
$ docker ps -a
ID                  IMAGE               COMMAND                CREATED              STATUS              PORTS
193bab2528b4        lucid64:latest      sleep 60               3 seconds ago        Exit 255            

..however given the advanced nature of this feature, I can live with the current behavior.

Thanks Gabriel.

There's another problem: as currently implemented, external mount-binds are
added to the container's Config object, which will be inherited by any
image committed from it, and most likely used as a default by any other
host running it.

It's important that we keep host-specific mounts scoped to that one host,
otherwise it will introduce unwanted side effects and break the portability
of containers.

On Fri, Jun 7, 2013 at 1:11 AM, Gabriel Monroy notifications@github.comwrote:

@unclejack https://github.com/unclejack I've cleaned up the PR as
follows:

With regard to error handling on missing host/container directories, I
find the errors produced by lxc-start to be sufficient, but I'll let
others be the judge..

Missing host directory:

$ docker run -b /missing:/tmp -t -i lucid64 bash
lxc-start: No such file or directory - failed to mount '/missing' on '/usr/lib/lxc/root//tmp'
lxc-start: failed to setup the mount entries for '365878af00f71ee024692755c43a94d39c7bc7a0905186d9668f93897d564399'
lxc-start: failed to setup the container
lxc-start: invalid sequence number 1. expected 2
lxc-start: failed to spawn '365878af00f71ee024692755c43a94d39c7bc7a0905186d9668f93897d564399'

Missing container directory:

$ docker run -b /tmp:/missing -t -i lucid64 bash
lxc-start: No such file or directory - failed to mount '/tmp' on '/usr/lib/lxc/root//missing'
lxc-start: failed to setup the mount entries for 'ddb1888e82f3a7672f365123e67559bca4b707afe2ca7e06da36ee8cfb24c75b'
lxc-start: failed to setup the container
lxc-start: invalid sequence number 1. expected 2
lxc-start: failed to spawn 'ddb1888e82f3a7672f365123e67559bca4b707afe2ca7e06da36ee8cfb24c75b'

It's important to note running the container in daemon mode (-d) swallows
the error:

$ docker run -b /tmp:/missing -d lucid64 sleep 60
193bab2528b4
$ docker ps -a
ID IMAGE COMMAND CREATED STATUS PORTS
193bab2528b4 lucid64:latest sleep 60 3 seconds ago Exit 255

..however given the advanced nature of this feature, I can live with the
current behavior.


Reply to this email directly or view it on GitHubhttps://github.com/dotcloud/docker/pull/602#issuecomment-19080164
.

gabrtv commented Jun 6, 2013

Agreed. We certainly don't want this inherited. I'm happy to take a closer look, but in the meantime is there a different strategy you have in mind?

gabrtv commented Jun 7, 2013

@solomonstre After taking a closer look, I can't see a quick & easy way to remove binds from the Config object. The relevant code path seems to be:

CLI
  • func (cli *DockerCli) CmdRun(args ...string) error
    • func ParseRun(args []string, capabilities *Capabilities) (*Config, *flag.FlagSet, error)
    • func (cli *DockerCli) call(method, path string, data interface{}) ([]byte, int, error)
API
  • func postContainersCreate(srv *Server, version float64, w http.ResponseWriter, r *http.Request, vars map[string]string)
    • func (srv *Server) ContainerCreate(config *Config) (string, error)
      • func (builder *Builder) Create(config *Config) (*Container, error)
  • func postContainersStart(srv *Server, version float64, w http.ResponseWriter, r *http.Request, vars map[string]string) error
    • func (srv *Server) ContainerStart(name string) error
      • func (container *Container) Start() error

I can see two options for achieving the goal you outlined:

  1. Keep Binds in the Config, but try to exclude them during ContainerCommit
  2. Introduce a new "HostConfig" used during container start operations

The second option would involve:

  • Changing ParseRun to return a new HostConfig containing bind mounts and anything else
  • Changing CmdRun to POST to /containers/:id/start with the HostConfig body (instead of the current nil body)
  • Changing postContainersStart to deserialize the HostConfig and pass it to srv.ContainerStart
  • Make srv.ContainerStart and container.Start take a HostConfig

Thoughts? Am I missing something?

@ghost ghost assigned shykes Jun 12, 2013

Collaborator

shykes commented Jun 12, 2013

I agree with option 2. It makes sense to have a HostConfig that is separate from the image's config.
Later this can be used as a foundation for a configuration system. HostConfig values could be defined
in a cascading way, much like CSS: in a top-level configuration file, as command-line options to the daemon,
as command-line options to the run (eg. the subject of this present conversation).

Other things that I see applying to HostConfig:

* DNS overrides (currently in 'docker run -dns')
* Passing physical interfaces to a container (eg. eth0)
* Exposing device files to a container (eg. /dev/fuse)
* Middleware hooks

Two points to discuss:

  1. Should HostConfig fields have their own command-line flags, eg '-b' for bind-mount, '-dns' for dns config etc.? Or
    should we define a single flag for setting the field of your choice, eg. '-o mounts/pgdata=/var/lib/postgres:/mnt/postgres-data'
    or '-o dns=8.8.8.8'. I'm thinking we stick to regular flags for now, and figure out a generic system later, when it's needed.

  2. Host mounts should always have a corresponding data volume (as created by -v). We can do that in 2 ways:

    a) -b must be preceded by an explicit -v, or it fails with "No data volume declared at /var/lib/postgres, cannot mount".
    b) -b creates the missing data volume on the fly when needed. This way listing a container's volumes will always yield
    the expected result (which is to show all "special" persistent directories), and the next commit will inherit
    the new data volume (without inheriting the host-specific part).

Let me know if you'd like to get some help on this, this PR is high on the list so if we can parallelize, we should.

Thanks!

gabrtv commented Jun 12, 2013

Should HostConfig fields have their own command-line flags

To me the distinction between what goes in HostConfig versus Config is an implementation detail that most users won't be concerned with. I lean toward leaving regular flags.

Host mounts should always have a corresponding data volume (as created by -v)

From a UX standpoint having -b create the volume seems friendlier, but is it too magical? To be honest, I'm not very familiar with the current volumes implementation. I'll defer to others on what makes the most sense here.

I understand the high priority and am happy to take a crack at the "MVPR", which to me excludes (for now):

  • Cascading configuration
  • Moving other Config items into HostConfig (e.g. -dns)

and includes:

Changing ParseRun to return a new HostConfig containing bind mounts
Changing CmdRun to POST to /containers/:id/start with the HostConfig body (instead of the current nil body)
Changing postContainersStart to deserialize the HostConfig and pass it to srv.ContainerStart
Make srv.ContainerStart and container.Start take a HostConfig

...as well as whatever we decide for '-v' requirements, plus fixing the multitude of tests that will be broken from changing function signatures for something like Container.Start.

With regard to parallelization, it seems like the HostConfig struct, function signatures, and new Start implementations need to happen first.

Thoughts @solomonstre?

Collaborator

shykes commented Jun 12, 2013

Sounds good to me, I think we're on the same page. Go for it! I would recommend asking for feedback frequently to avoid wasting your time if we start diverging :)

Re: magical interactions between -v and -b, what do you guys thing @creack @vieux @jpetazzo @unclejack (and anybody else with actual experience playing with docker + volumes)

Contributor

unclejack commented Jun 12, 2013

@shykes I wouldn't worry about it too much right now, docker is not yet stable and production ready, so we'll be able to make fixes and changes.

in my opinion, -v and -b should be able to work together for now. We can add some special checks later to prevent the nesting of bind mounts within volumes if that becomes a problem.

gabrtv commented Jun 21, 2013

Merged with current master. The relevant changes are in this commit: ffe794f

This turned out to be fairly straightforward. HostConfig is now passed through all container Start operations. That's where bind mount configuration is stored. Should be fairly extensible. Over to you @shykes!

Collaborator

vieux commented Jun 21, 2013

This will require a bump of the remote API version (and the doc which goes with it)

I know this is an expected behaviour, but would be nice if -b could create the directory in the container ?
(have a working docker run -b /tmp:/missing -t -i lucid64 bash)

gabrtv commented Jun 21, 2013

@vieux that should handle creating missing directories. I added test coverage too.

With regard to bumping API version and docs, is that something you'd like me to do in this PR?

Collaborator

vieux commented Jun 21, 2013

@shykes your call about the api version,
I say we can merge this PR, merge your PR about build and version 1.3, and add the doc of this PR in version 1.3 (not need to have api 1.3 for about 1/2 day(s) and jumping to 1.4)

Collaborator

vieux commented Jun 24, 2013

@gabrtv could you bump to master and, regarding the doc:

Update the what's new section for the 1.3 api in docs/sources/api/docker_remote_api.rst
and update docs/sources/api/docker_remote_api_v1.3.rst

Thanks

gabrtv commented Jun 24, 2013

@vieux docs updated and latest master merged. Let me know if you need anything else on this PR.

Collaborator

vieux commented Jun 24, 2013

@gabrtv thank it looks very good, one thing docker run -b /:. -i -t base bash fails (expected) but you can't quit the client. Is that possible for you to prevent this ?

Otherwise LGTM

Collaborator

vieux commented Jun 24, 2013

awesome, thanks

@shykes shykes commented on an outdated diff Jun 24, 2013

@@ -551,11 +551,17 @@ func deleteImages(srv *Server, version float64, w http.ResponseWriter, r *http.R
}
func postContainersStart(srv *Server, version float64, w http.ResponseWriter, r *http.Request, vars map[string]string) error {
+ hostConfig := &HostConfig{}
+
+ if err := json.NewDecoder(r.Body).Decode(hostConfig); err != nil {
@shykes

shykes Jun 24, 2013

Collaborator

I think we should continue accepting an empty body, in which case we would pass an empty HostConfig. That way we preserve compatibility with older clients.

gabrtv commented Jun 24, 2013

@shykes good catch. fixed and updated docs.

Collaborator

shykes commented Jun 24, 2013

When I run 'docker help run' I see the following output:

$ docker help run
[...]
  -b=[]: Bind mount a volume from the host
[...]

It's difficult to guess what to pass exactly. Note that other flags suffer from the same problem - but still, it would be nice to give a user-friendly hint.

(edited to show the right flag :)

Collaborator

shykes commented Jun 24, 2013

(I edited the previous comment to show the correct flag)

gabrtv commented Jun 24, 2013

@shykes just merged master again and double checked the test suite. let me know if there's anything else you need here.

gabrtv commented Jun 24, 2013

@shykes -b flags are now treated as -v flags early on in ParseRun. Seems to work on my end:

# docker run -t -i -b /tmp:/missing base sleep 2 
# docker inspect 3dac85f068de
[2013/06/24 23:51:09 GET /v1.3/containers/3dac85f068de/json
{
    "ID": "3dac85f068de8fa208f486134b008892c219f6f8c4a22f1491a8ee8cd99b4f7f",
    "Created": "2013-06-24T23:50:54.593031323Z",
    "Path": "sleep",
    "Args": [
        "2"
    ],
    "Config": {
        "Hostname": "3dac85f068de",
        "User": "",
        "Memory": 0,
        "MemorySwap": 0,
        "CpuShares": 0,
        "AttachStdin": true,
        "AttachStdout": true,
        "AttachStderr": true,
        "PortSpecs": null,
        "Tty": true,
        "OpenStdin": true,
        "StdinOnce": true,
        "Env": null,
        "Cmd": [
            "sleep",
            "2"
        ],
        "Dns": null,
        "Image": "base",
        "Volumes": {
            "/missing": {}
        },
        "VolumesFrom": ""
    },
    "State": {
        "Running": false,
        "Pid": 0,
        "ExitCode": 0,
        "StartedAt": "2013-06-24T23:50:54.596669666Z",
        "Ghost": false
    },
    "Image": "b750fe79269d2ec9a3c593ef05b4332b1d1a02a62b4accb2c21d589ff2f5f2dc",
    "NetworkSettings": {
        "IPAddress": "",
        "IPPrefixLen": 0,
        "Gateway": "",
        "Bridge": "",
        "PortMapping": null
    },
    "SysInitPath": "/root/go/bin/docker",
    "ResolvConfPath": "/etc/resolv.conf",
    "Volumes": {
        "/missing": "047de3ada91608514da74f1eb9d76853c636c51a5483ad2983f7b829a80195a7"
    },
    "Binds": [
        {
            "SrcPath": "/tmp",
            "DstPath": "/missing",
            "Mode": "rw"
        }
    ]
}]```
Collaborator

shykes commented Jun 25, 2013

Hey @gabrtv, I'm pushing some amendments to this branch: https://github.com/dotcloud/docker/tree/111-bind-mounts-AMENDMENTS

I don't have permission to update your pull request, would you mind pulling them in? I have another commit or two coming. These fix the problem we talked about, eg. getting the binds and volumes to play nice with each other completely.

I still need to push 2 commits to fix 2 things:

  1. Your test doesn't pass, but the functionality it tests actually works (from another out-of-band test). Trying to figure out what's wrong.

  2. I temporarily disabled ro mode. It's already coded, but I'm breaking down commits for clarity.

gabrtv commented Jun 25, 2013

@shykes i'm out of office today. I'm happy to pick this up tonight or tomorrow. In the meantime I granted you write access to my fork. Feel free to update the PR.

Btw, I thought I fixed that broken test in: 1cf32c1

Thanks for helping take this across the finish line!

Collaborator

shykes commented Jun 25, 2013

Thanks @gabrtv for giving me access, I pushed my amendments to you branch, I will delete my other branch.

@vieux yes, that test fails and I haven't found out why yet - the feature it is testing seems to work fine. I think this is the last point keeping us from merging.

Collaborator

vieux commented Jun 26, 2013

@shykes there are 2 issues.

  1. the whole functionality is broken, docker run -b /tmp:/tmp base ls /tmp doesn't work
  2. You need to add volumes to the tests (it's done by parseRun) lines 1261 and 1293, like this :
 container, err := NewBuilder(runtime).Create(&Config{
                 Image:   GetTestImage(runtime).ID,
+                Volumes: map[string]struct{}{"/tmp": struct{}{}},
                 Cmd:     []string{"ls", "/tmp"},
         },

I think problem 2 should be solved by latest commit - the test uses ParseRun now.

@solomonstre
@getdocker

On Wed, Jun 26, 2013 at 8:29 AM, Victor Vieux notifications@github.com
wrote:

@shykes there are 2 issues.

  1. the whole functionality is broken, docker run -b /tmp:/tmp base ls /tmp doesn't work
  2. You need to add volumes to the tests (it's done by parseRun) lines 1261 and 1293, like this :
    container, err := NewBuilder(runtime).Create(&Config{
    Image: GetTestImage(runtime).ID,
    •            Volumes: map[string]struct{}{"/tmp": struct{}{}},
                 Cmd:     []string{"ls", "/tmp"},
      

},

Reply to this email directly or view it on GitHub:
dotcloud#602 (comment)

gabrtv commented Jun 26, 2013

@shykes @vieux tests are now passing with a merge of current master. A couple notes:

  1. Some + typos ended up in the LXC template and were breaking the base functionality
  2. There was a dupe init of container.VolumesRW that was breaking RW (everything was RO)
  3. As @vieux noted, the test code needed to add Volumes to the container Config since ParseRun isn't being called

I'm not sure where @shykes test factoring code went -- it seemed like a better testing approach -- but this works.

Contributor

creack commented Jun 26, 2013

I really don't like the unit-test refactoring. Now, where there is an issue, it always come from utils_test.go, so we need to look for the failed test.
Otherwise, LGTM.

Collaborator

shykes commented Jun 26, 2013

@creack I understand what you mean. It's a tradeoff either way: either we have long and repetitive tests with exact information on which line failed - or we have very short and readable tests with less precise line information.

I think the reason you need exact line information right now is precisely because our tests are too long and too repetitive. With a clean table-driven test, line information is not as important, and not sufficient anyway since the same line might be used for multiple tests in a loop. See build_test.go for an example.

@ptone ptone referenced this pull request in ptone/jiffylab Jun 26, 2013

Open

setup lab-wide shared folder #12

Collaborator

shykes commented Jun 26, 2013

I'm rebasing for cleanness... Brace yourselves :)

Collaborator

shykes commented Jun 26, 2013

LGTM

@shykes shykes pushed a commit that referenced this pull request Jun 26, 2013

Solomon Hykes Merge pull request #602 from gabrtv/111-bind-mounts
+ Runtime: mount volumes from a host directory with 'docker run -b'
3e29695

@shykes shykes merged commit 3e29695 into moby:master Jun 26, 2013

@gabrtv gabrtv deleted the gabrtv:111-bind-mounts branch Jun 26, 2013

Contributor

denibertovic commented Jun 27, 2013

any plan on when the new release is going to be?

We're aiming for tomorrow or friday.

@solomonstre
@getdocker

On Thu, Jun 27, 2013 at 2:47 AM, Deni Bertovic notifications@github.com
wrote:

any plan on when the new release is going to be?

Reply to this email directly or view it on GitHub:
dotcloud#602 (comment)

Contributor

denibertovic commented Jun 27, 2013

pure awesomeness! 👍

stigi commented Jun 27, 2013

👍 you guys rock! epic pull request 💯

👍

👍 great one!

You guys rock so hard 👍

Contributor

kencochrane commented Jul 2, 2013

I wish we added better docs before we pushed this live. There are no examples on how to use it, and the only references I could find were in the API docs and a small reference in the run command's flag list.

These binds/mounts are persisted after a restart of the container, but they seem to be broken. That is to say, I see them listed in mount on the container but the directory is empty.

Client version: 0.4.8
Server version: 0.4.8
Go version: go1.1

OS: Ubuntu 13.04

Collaborator

vieux commented Jul 8, 2013

@jwmarshall it'll be fixed bu #1102

@vieux Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment