Persistent data volumes #111

Closed
JeremyGrosser opened this Issue Mar 20, 2013 · 43 comments

Comments

Projects
None yet
@JeremyGrosser
Contributor

JeremyGrosser commented Mar 20, 2013

A lot of applications store nontrivial amounts of data on disk and need it to be persisted outside the scope of the aufs filesystem.

Proposal:

docker run base --bind /path/outside/container:/mnt/path/inside/container /path/to/crazydb

Bonus points if you can use variable substitution in the bind path names eg.

docker run base --bind '/mnt/$Id/mail:/var/spool/mail' /usr/sbin/postfix

Presumably this feature would manifest itself in config.json somewhat like this:

"Mountpoint": {
  "Bind": [
    {"OutsidePath": "/path/outside/container",
     "InsidePath": "/path/inside/container"}
  ]
}

@shykes shykes closed this Mar 21, 2013

@shykes shykes reopened this Mar 26, 2013

@shykes shykes referenced this issue Mar 26, 2013

Closed

Data volumes #3

@sa2ajj

This comment has been minimized.

Show comment
Hide comment
@sa2ajj

sa2ajj Mar 26, 2013

Contributor

would it be possible to have a some sort of --fstab option that'd result in adding lxc.mount.entry entries in the container's config file??

Contributor

sa2ajj commented Mar 26, 2013

would it be possible to have a some sort of --fstab option that'd result in adding lxc.mount.entry entries in the container's config file??

@sa2ajj

This comment has been minimized.

Show comment
Hide comment
@sa2ajj

sa2ajj Mar 26, 2013

Contributor

actually, there are two options here:

  • copy the given fstab verbatim and use lxc.mount = option
  • translate the content of the file to corresponding lxc.mount.entry
Contributor

sa2ajj commented Mar 26, 2013

actually, there are two options here:

  • copy the given fstab verbatim and use lxc.mount = option
  • translate the content of the file to corresponding lxc.mount.entry
@shykes

This comment has been minimized.

Show comment
Hide comment
@shykes

shykes Mar 26, 2013

Collaborator

The key principle to keep in mind is that we want to minimize how much the
container's execution environment depends on the host's.

On Tue, Mar 26, 2013 at 7:40 AM, Mikhail Sobolev
notifications@github.comwrote:

actually, there are two options here:

  • copy the given fstab verbatim and use lxc.mount = option
  • translate the content of the file to corresponding lxc.mount.entry


Reply to this email directly or view it on GitHubhttps://github.com/dotcloud/docker/issues/111#issuecomment-15462016
.

Collaborator

shykes commented Mar 26, 2013

The key principle to keep in mind is that we want to minimize how much the
container's execution environment depends on the host's.

On Tue, Mar 26, 2013 at 7:40 AM, Mikhail Sobolev
notifications@github.comwrote:

actually, there are two options here:

  • copy the given fstab verbatim and use lxc.mount = option
  • translate the content of the file to corresponding lxc.mount.entry


Reply to this email directly or view it on GitHubhttps://github.com/dotcloud/docker/issues/111#issuecomment-15462016
.

@jpetazzo

This comment has been minimized.

Show comment
Hide comment
@jpetazzo

jpetazzo Mar 27, 2013

Contributor
  1. Short term.
    The command-line binding proposed by @synack would work great. That would make an easy way to persist data, with minimal "out of docker" instrumentation. My personal taste would be to reverse the args, e.g. dotcloud run base -volume /path/in/container=/path/on/host, but that's just me.
  2. Mid term.
    I don't know what we want in the config.json file. FTR, on the current dotCloud platform (which uses the cloudlets format, this is split between two parts: manifest and config. The manifest is the conceptual equivalent of a class definition. It says "to run this, I need one tcp port for SSH, and another for SQL; and also, /var/lib/mysql should be a persistent volume". The config is the instantiated version, so it tells exactly which port was allocated, which volume was binded, etc.
    It looks like we might have port information in the image json file (to mention "hey, that image exposes a service on port 5432, so by default, dotcloud run should automatically add -p 5432 unless overriden").
    If that's so, it would make sense to also mention which paths are supposed to be volumes, if only for mere introspection purposes.
    Then, if we implement container tagging, it would integrate very neatly to provide persistent data storage. I.E. by default, you get a tmpfs on each volume, but if the container is tagged, then volume foo is bound from e.g. /var/lib/docker/volumes/<containertag>/foo.
  3. Long term.
    I believe that storage providers will be an important feature. It's too early to discuss that in detail I guess; but the idea would be to allow docker to interface with storage systems like LVM, btrfs, iSCSI, NFS, glusterfs, ceph... The scheme used by Xen 3 for network and block devices is not perfect, but it's a good source of inspiration (TL,DR: it allows to specify that e.g. /dev/xvdk should be myiscsi:foobar, and it will offload to a myiscsi script the task of locating foobar and making it available, whatever that means; so it is fairly extendable without touching the core). Of course docker wouldn't implement all those interfaces, but provide something that makes it easy for everyone to hook up whatever they need in the system.
Contributor

jpetazzo commented Mar 27, 2013

  1. Short term.
    The command-line binding proposed by @synack would work great. That would make an easy way to persist data, with minimal "out of docker" instrumentation. My personal taste would be to reverse the args, e.g. dotcloud run base -volume /path/in/container=/path/on/host, but that's just me.
  2. Mid term.
    I don't know what we want in the config.json file. FTR, on the current dotCloud platform (which uses the cloudlets format, this is split between two parts: manifest and config. The manifest is the conceptual equivalent of a class definition. It says "to run this, I need one tcp port for SSH, and another for SQL; and also, /var/lib/mysql should be a persistent volume". The config is the instantiated version, so it tells exactly which port was allocated, which volume was binded, etc.
    It looks like we might have port information in the image json file (to mention "hey, that image exposes a service on port 5432, so by default, dotcloud run should automatically add -p 5432 unless overriden").
    If that's so, it would make sense to also mention which paths are supposed to be volumes, if only for mere introspection purposes.
    Then, if we implement container tagging, it would integrate very neatly to provide persistent data storage. I.E. by default, you get a tmpfs on each volume, but if the container is tagged, then volume foo is bound from e.g. /var/lib/docker/volumes/<containertag>/foo.
  3. Long term.
    I believe that storage providers will be an important feature. It's too early to discuss that in detail I guess; but the idea would be to allow docker to interface with storage systems like LVM, btrfs, iSCSI, NFS, glusterfs, ceph... The scheme used by Xen 3 for network and block devices is not perfect, but it's a good source of inspiration (TL,DR: it allows to specify that e.g. /dev/xvdk should be myiscsi:foobar, and it will offload to a myiscsi script the task of locating foobar and making it available, whatever that means; so it is fairly extendable without touching the core). Of course docker wouldn't implement all those interfaces, but provide something that makes it easy for everyone to hook up whatever they need in the system.
@sa2ajj

This comment has been minimized.

Show comment
Hide comment
@sa2ajj

sa2ajj Mar 27, 2013

Contributor

(Just for the record) I realized one thing: the bound directory should somehow excluded from what is being tracked as "changes". I am not sure if a straightforward implementation would work right away.

Contributor

sa2ajj commented Mar 27, 2013

(Just for the record) I realized one thing: the bound directory should somehow excluded from what is being tracked as "changes". I am not sure if a straightforward implementation would work right away.

@jpetazzo

This comment has been minimized.

Show comment
Hide comment
@jpetazzo

jpetazzo Mar 27, 2013

Contributor

That will actually work out of the box—because docker tracks changes by checking the AUFS layer, and a bind mount wouldn't show up in the layer.

Contributor

jpetazzo commented Mar 27, 2013

That will actually work out of the box—because docker tracks changes by checking the AUFS layer, and a bind mount wouldn't show up in the layer.

@tadev

This comment has been minimized.

Show comment
Hide comment

tadev commented Mar 29, 2013

+1 want

@titanous

This comment has been minimized.

Show comment
Hide comment
@titanous

titanous Mar 29, 2013

Contributor

👍 I want to see if I can get Ceph running in docker so that I can get docker running on Ceph.

Contributor

titanous commented Mar 29, 2013

👍 I want to see if I can get Ceph running in docker so that I can get docker running on Ceph.

@sa2ajj sa2ajj referenced this issue Apr 8, 2013

Closed

riak use case #351

@ghost ghost assigned creack Apr 8, 2013

@shykes

This comment has been minimized.

Show comment
Hide comment
@shykes

shykes Apr 8, 2013

Collaborator

Updated the title for clarity.

Collaborator

shykes commented Apr 8, 2013

Updated the title for clarity.

@shykes

This comment has been minimized.

Show comment
Hide comment
@shykes

shykes Apr 8, 2013

Collaborator

So, here's the current plan.

1. Creating data volumes

At container creation, parts of a container's filesystem can be mounted as separate data volumes. Volumes are defined with the -v flag.

For example:

$ docker run -v /var/lib/postgres -v /var/log postgres /usr/bin/postgres

In this example, a new container is created from the 'postgres' image. At the same time, docker creates 2 new data volumes: one will be mapped to the container at /var/lib/postgres, the other at /var/log.

2 important notes:

  1. Volumes don't have top-level names. At no point does the user provide a name, or is a name given to him. Volumes are identified by the path at which they are mounted inside their container.

  2. The user doesn't choose the source of the volume. Docker only mounts volumes it created itself, in the same way that it only runs containers that it created itself. That is by design.

2. Sharing data volumes

Instead of creating its own volumes, a container can share another container's volumes. For example:

$ docker run --volumes-from $OTHER_CONTAINER_ID postgres /usr/local/bin/postgres-backup

In this example, a new container is created from the 'postgres' example. At the same time, docker will re-use the 2 data volumes created in the previous example. One volume will be mounted on the /var/lib/postgres of both containers, and the other will be mounted on the /var/log of both containers.

3. Under the hood

Docker stores volumes in /var/lib/docker/volumes. Each volume receives a globally unique ID at creation, and is stored at /var/lib/docker/volumes/ID.

At creation, volumes are attached to a single container - the source of truth for this mapping will be the container's configuration.

Mounting a volume consists of calling "mount --bind" from the volume's directory to the appropriate sub-directory of the container mountpoint. This may be done by Docker itself, or farmed out to lxc (which supports mount-binding) if possible.

4. Backups, transfers and other volume operations

Volumes sometimes need to be backed up, transfered between hosts, synchronized, etc. These operations typically are application-specific or site-specific, eg. rsync vs. S3 upload vs. replication vs...

Rather than attempting to implement all these scenarios directly, Docker will allow for custom implementations using an extension mechanism.

5. Custom volume handlers

Docker allows for arbitrary code to be executed against a container's volumes, to implement any custom action: backup, transfer, synchronization across hosts, etc.

Here's an example:

$ DB=$(docker run -d -v /var/lib/postgres -v /var/log postgres /usr/bin/postgres)

$ BACKUP_JOB=$(docker run -d --volumes-from $DB shykes/backuper /usr/local/bin/backup-postgres --s3creds=$S3CREDS)

$ docker wait $BACKUP_JOB

Congratulations, you just implemented a custom volume handler, using Docker's built-in ability to 1) execute arbitrary code and 2) share volumes between containers.

Collaborator

shykes commented Apr 8, 2013

So, here's the current plan.

1. Creating data volumes

At container creation, parts of a container's filesystem can be mounted as separate data volumes. Volumes are defined with the -v flag.

For example:

$ docker run -v /var/lib/postgres -v /var/log postgres /usr/bin/postgres

In this example, a new container is created from the 'postgres' image. At the same time, docker creates 2 new data volumes: one will be mapped to the container at /var/lib/postgres, the other at /var/log.

2 important notes:

  1. Volumes don't have top-level names. At no point does the user provide a name, or is a name given to him. Volumes are identified by the path at which they are mounted inside their container.

  2. The user doesn't choose the source of the volume. Docker only mounts volumes it created itself, in the same way that it only runs containers that it created itself. That is by design.

2. Sharing data volumes

Instead of creating its own volumes, a container can share another container's volumes. For example:

$ docker run --volumes-from $OTHER_CONTAINER_ID postgres /usr/local/bin/postgres-backup

In this example, a new container is created from the 'postgres' example. At the same time, docker will re-use the 2 data volumes created in the previous example. One volume will be mounted on the /var/lib/postgres of both containers, and the other will be mounted on the /var/log of both containers.

3. Under the hood

Docker stores volumes in /var/lib/docker/volumes. Each volume receives a globally unique ID at creation, and is stored at /var/lib/docker/volumes/ID.

At creation, volumes are attached to a single container - the source of truth for this mapping will be the container's configuration.

Mounting a volume consists of calling "mount --bind" from the volume's directory to the appropriate sub-directory of the container mountpoint. This may be done by Docker itself, or farmed out to lxc (which supports mount-binding) if possible.

4. Backups, transfers and other volume operations

Volumes sometimes need to be backed up, transfered between hosts, synchronized, etc. These operations typically are application-specific or site-specific, eg. rsync vs. S3 upload vs. replication vs...

Rather than attempting to implement all these scenarios directly, Docker will allow for custom implementations using an extension mechanism.

5. Custom volume handlers

Docker allows for arbitrary code to be executed against a container's volumes, to implement any custom action: backup, transfer, synchronization across hosts, etc.

Here's an example:

$ DB=$(docker run -d -v /var/lib/postgres -v /var/log postgres /usr/bin/postgres)

$ BACKUP_JOB=$(docker run -d --volumes-from $DB shykes/backuper /usr/local/bin/backup-postgres --s3creds=$S3CREDS)

$ docker wait $BACKUP_JOB

Congratulations, you just implemented a custom volume handler, using Docker's built-in ability to 1) execute arbitrary code and 2) share volumes between containers.

@shykes

This comment has been minimized.

Show comment
Hide comment
@shykes

shykes Apr 8, 2013

Collaborator

One aspect of the spec which is not yet determined: specifying read-only mounts. Any preference on the best way to extend the syntax?

Collaborator

shykes commented Apr 8, 2013

One aspect of the spec which is not yet determined: specifying read-only mounts. Any preference on the best way to extend the syntax?

@glasser

This comment has been minimized.

Show comment
Hide comment
@glasser

glasser Apr 8, 2013

Contributor

Can you specify --volumes-from more than once?

Contributor

glasser commented Apr 8, 2013

Can you specify --volumes-from more than once?

@shykes

This comment has been minimized.

Show comment
Hide comment
@shykes

shykes Apr 8, 2013

Collaborator

@glasser I didn't consider it. One obvious problem is that 2 containers might each have a volume mounted on the same path - in which case the 2 volumes would conflict.

I'm guessing you have a specific use case in mind? :)

Collaborator

shykes commented Apr 8, 2013

@glasser I didn't consider it. One obvious problem is that 2 containers might each have a volume mounted on the same path - in which case the 2 volumes would conflict.

I'm guessing you have a specific use case in mind? :)

@glasser

This comment has been minimized.

Show comment
Hide comment
@glasser

glasser Apr 8, 2013

Contributor

Sure, but that should be something that can be statically checked by docker while building the container, right?

And yes :)

Contributor

glasser commented Apr 8, 2013

Sure, but that should be something that can be statically checked by docker while building the container, right?

And yes :)

@shykes

This comment has been minimized.

Show comment
Hide comment
@shykes

shykes Apr 8, 2013

Collaborator

Would docker fail in the case of a conflict?

It would help if you shared the use case.

Collaborator

shykes commented Apr 8, 2013

Would docker fail in the case of a conflict?

It would help if you shared the use case.

@shykes

This comment has been minimized.

Show comment
Hide comment
@shykes

shykes Apr 8, 2013

Collaborator

(I guess one other possibility could be to specify a container-specific prefix, so eg. volumes from container1 could be mounted at /data/container1/ and volumes from container2 would be mounted at /data/container2/)

Collaborator

shykes commented Apr 8, 2013

(I guess one other possibility could be to specify a container-specific prefix, so eg. volumes from container1 could be mounted at /data/container1/ and volumes from container2 would be mounted at /data/container2/)

@glasser

This comment has been minimized.

Show comment
Hide comment
@glasser

glasser Apr 8, 2013

Contributor

Sure, the idea here is (with read-only mounts) that programs would declare their dependencies from our ecosystem of versioned packages. We could keep around a container for each package version, and then to run programs, we join the containers of all the dependencies.

But there are much simpler use cases. Imagine that your backup-postgres script was actually, eg, "copy Mongo to postgres" (eg, https://github.com/stripe/mosql). Presumably that task would want to --volumes-from $POSTGRESCONTAINER --volumes-from $MONGOCONTAINER?

Contributor

glasser commented Apr 8, 2013

Sure, the idea here is (with read-only mounts) that programs would declare their dependencies from our ecosystem of versioned packages. We could keep around a container for each package version, and then to run programs, we join the containers of all the dependencies.

But there are much simpler use cases. Imagine that your backup-postgres script was actually, eg, "copy Mongo to postgres" (eg, https://github.com/stripe/mosql). Presumably that task would want to --volumes-from $POSTGRESCONTAINER --volumes-from $MONGOCONTAINER?

@titanous

This comment has been minimized.

Show comment
Hide comment
@titanous

titanous Apr 8, 2013

Contributor

@shykes How do I expose a specific mountpoint inside of a container?

Example

I want to containerize Ceph, which is typically configured with one OSD process per drive (drives are formatted with XFS or btrfs). What I'd like to do is boot up N docker containers where N is the number of drives that I have and expose a drive (just the mounted volume, actually) to each of them.

Contributor

titanous commented Apr 8, 2013

@shykes How do I expose a specific mountpoint inside of a container?

Example

I want to containerize Ceph, which is typically configured with one OSD process per drive (drives are formatted with XFS or btrfs). What I'd like to do is boot up N docker containers where N is the number of drives that I have and expose a drive (just the mounted volume, actually) to each of them.

@shykes

This comment has been minimized.

Show comment
Hide comment
@shykes

shykes Apr 8, 2013

Collaborator

On Mon, Apr 8, 2013 at 1:42 PM, Jonathan Rudenberg <notifications@github.com

wrote:

@shykes https://github.com/shykes How do I expose a specific mountpoint
inside of a container?

Example

I want to containerize Ceph, which is typically configured with one OSD
process per drive (drives are formatted with XFS or btrfs). What I'd like
to do is boot up N docker containers where N is the number of drives that I
have and expose a drive (just the mounted volume, actually) to each of them.

I don't know how Ceph works. Beyond fine-grained control over which volume
is stored where on the host filesystem, would those containers require any
sort of runtime privileges? Eg. device access etc.

If not, I'm going to assume your example can be generalized to "How can I
specify which volume is stored where on the host".

There's a 2-part answer to that

  • Answer part 1: if specifying where all docker volumes are stored on the
    host is enough - and in a lot of cases it is - then the answer is to
    symlink /var/lib/docker/volumes to the path of your choice.
  • Answer part 2: if really you need fine-grained control (as it seems is
    the case in this example), you need to configure Docker with a hook. The
    format and UI of these hooks is not yet defined, and suggestions are
    welcome :)
Collaborator

shykes commented Apr 8, 2013

On Mon, Apr 8, 2013 at 1:42 PM, Jonathan Rudenberg <notifications@github.com

wrote:

@shykes https://github.com/shykes How do I expose a specific mountpoint
inside of a container?

Example

I want to containerize Ceph, which is typically configured with one OSD
process per drive (drives are formatted with XFS or btrfs). What I'd like
to do is boot up N docker containers where N is the number of drives that I
have and expose a drive (just the mounted volume, actually) to each of them.

I don't know how Ceph works. Beyond fine-grained control over which volume
is stored where on the host filesystem, would those containers require any
sort of runtime privileges? Eg. device access etc.

If not, I'm going to assume your example can be generalized to "How can I
specify which volume is stored where on the host".

There's a 2-part answer to that

  • Answer part 1: if specifying where all docker volumes are stored on the
    host is enough - and in a lot of cases it is - then the answer is to
    symlink /var/lib/docker/volumes to the path of your choice.
  • Answer part 2: if really you need fine-grained control (as it seems is
    the case in this example), you need to configure Docker with a hook. The
    format and UI of these hooks is not yet defined, and suggestions are
    welcome :)
@jpetazzo

This comment has been minimized.

Show comment
Hide comment
@jpetazzo

jpetazzo Apr 10, 2013

Contributor

Question 1: if I want a specific data volume to reside on a specific filesystem, what should I do?
Question 2: what's the lifecycle of a volume? i.e. how does it get deleted?

Contributor

jpetazzo commented Apr 10, 2013

Question 1: if I want a specific data volume to reside on a specific filesystem, what should I do?
Question 2: what's the lifecycle of a volume? i.e. how does it get deleted?

@jpetazzo

This comment has been minimized.

Show comment
Hide comment
@jpetazzo

jpetazzo Apr 10, 2013

Contributor

Question 3: if, down the road, we want to introduce support for container migration from a docker host to another (or if one is to implement it with the current API), what's the suggested approach?

Contributor

jpetazzo commented Apr 10, 2013

Question 3: if, down the road, we want to introduce support for container migration from a docker host to another (or if one is to implement it with the current API), what's the suggested approach?

@shykes

This comment has been minimized.

Show comment
Hide comment
@shykes

shykes Apr 10, 2013

Collaborator

On Tue, Apr 9, 2013 at 6:37 PM, Jérôme Petazzoni
notifications@github.comwrote:

Question 1: if I want a specific data volume to reside on a specific
filesystem, what should I do?

See above my 2-part answer to @titanous. I think it's the same request.

Question 2: what's the lifecycle of a volume? i.e. how does it get deleted?

Good question. The thinking so far is to add an option to 'rm' so that
'docker rm $ID --volumes' removes a container's volumes. This would fail if
any running container has the volumes mounted.

This means volumes can outlive the volumes they're attached to. To avoid
littering the ground with orphan volumes, we can preserve enough metadata
to refer to a container's volumes even after the container has been removed
(the storage requirements are basically zero).

In general, I prefer erring on the side of "oh noz, I need to garbage
collect orphan volumes" rather than "oops I just removed the production
database by mistake".

Collaborator

shykes commented Apr 10, 2013

On Tue, Apr 9, 2013 at 6:37 PM, Jérôme Petazzoni
notifications@github.comwrote:

Question 1: if I want a specific data volume to reside on a specific
filesystem, what should I do?

See above my 2-part answer to @titanous. I think it's the same request.

Question 2: what's the lifecycle of a volume? i.e. how does it get deleted?

Good question. The thinking so far is to add an option to 'rm' so that
'docker rm $ID --volumes' removes a container's volumes. This would fail if
any running container has the volumes mounted.

This means volumes can outlive the volumes they're attached to. To avoid
littering the ground with orphan volumes, we can preserve enough metadata
to refer to a container's volumes even after the container has been removed
(the storage requirements are basically zero).

In general, I prefer erring on the side of "oh noz, I need to garbage
collect orphan volumes" rather than "oops I just removed the production
database by mistake".

@shykes

This comment has been minimized.

Show comment
Hide comment
@shykes

This comment has been minimized.

Show comment
Hide comment
@shykes

shykes Apr 10, 2013

Collaborator

On Wednesday, April 10, 2013, Jérôme Petazzoni wrote:

[...] won't that lead to something way more complicated than the
alternate proposal?
What was wrong with the alternate proposal [...] ?

To repeat my previous comment: Docker cannot allow arbitrary outside
bind-mounts at container runtime, that would break the repeatability of a
run, and even more importantly would require out-of-band host configuration
and operation. "Run this container with the following command, but first
make sure you create a directory call /mnt/foo/bar, then make sure
blablbla." This is exactly what docker is trying to avoid.

The command (and soon the API call) for running a container must always be
the same regardless of how storage (or networking) is implemented under the
hood. Otherwise Docker becomes useless as a component for automating a
distributed system. That is why I couldn't accept @sa2ajj 's pull request
(sorry!) or your proposal.

The ability to customize storage backends is very desirable! It just can't
be exposed in the runtime API. Which is why it requires hooks.

can docker decide when it is appropriate to remove a persistent volume?

When the user types "docker rm --volumes".

Isn't explicit better than implicit?

Yes.

(container migration), it is indeed an elegant approach, but it
completely bars the way to use CRIU and modern container migration
techniques (which would require some cooperation some docker anyway).

No, it doesn't. The migration container can be instrumented by a system
which makes appropriate docker calls, or it can make the calls itself once
we expose an appropriately powerful introspection api.

Collaborator

shykes commented Apr 10, 2013

On Wednesday, April 10, 2013, Jérôme Petazzoni wrote:

[...] won't that lead to something way more complicated than the
alternate proposal?
What was wrong with the alternate proposal [...] ?

To repeat my previous comment: Docker cannot allow arbitrary outside
bind-mounts at container runtime, that would break the repeatability of a
run, and even more importantly would require out-of-band host configuration
and operation. "Run this container with the following command, but first
make sure you create a directory call /mnt/foo/bar, then make sure
blablbla." This is exactly what docker is trying to avoid.

The command (and soon the API call) for running a container must always be
the same regardless of how storage (or networking) is implemented under the
hood. Otherwise Docker becomes useless as a component for automating a
distributed system. That is why I couldn't accept @sa2ajj 's pull request
(sorry!) or your proposal.

The ability to customize storage backends is very desirable! It just can't
be exposed in the runtime API. Which is why it requires hooks.

can docker decide when it is appropriate to remove a persistent volume?

When the user types "docker rm --volumes".

Isn't explicit better than implicit?

Yes.

(container migration), it is indeed an elegant approach, but it
completely bars the way to use CRIU and modern container migration
techniques (which would require some cooperation some docker anyway).

No, it doesn't. The migration container can be instrumented by a system
which makes appropriate docker calls, or it can make the calls itself once
we expose an appropriately powerful introspection api.

@jpetazzo

This comment has been minimized.

Show comment
Hide comment
@jpetazzo

jpetazzo Apr 10, 2013

Contributor

The proposal didn't require any out-of-band configuration and didn't break
repeatability of a run.

Specifying "-v=/var/lib/mysql=/mnt/mysql" doesn't "break repeatability"
more than "-p :3306".
Because the intent is very different between "-v=/var/lib/mysql" (resp. "-p
3306") and "-v=/var/lib/mysql=/mnt/mysql" (resp. "-p :3306"). In one case,
you're running a generic container, without much concern for its actual
state, context, and side-effects. In the other, you're running a specific
container, with well-defined expectations about the data it will use, and
the way it will be accessible from other hosts. Obviously this can be
repeated only in the appropriate context, and (in most cases) only once at
a time.

If the intent is to provide a 100% repeatable interface, then we should
also remove "-p :X" since it bears exactly the same issue.

Contributor

jpetazzo commented Apr 10, 2013

The proposal didn't require any out-of-band configuration and didn't break
repeatability of a run.

Specifying "-v=/var/lib/mysql=/mnt/mysql" doesn't "break repeatability"
more than "-p :3306".
Because the intent is very different between "-v=/var/lib/mysql" (resp. "-p
3306") and "-v=/var/lib/mysql=/mnt/mysql" (resp. "-p :3306"). In one case,
you're running a generic container, without much concern for its actual
state, context, and side-effects. In the other, you're running a specific
container, with well-defined expectations about the data it will use, and
the way it will be accessible from other hosts. Obviously this can be
repeated only in the appropriate context, and (in most cases) only once at
a time.

If the intent is to provide a 100% repeatable interface, then we should
also remove "-p :X" since it bears exactly the same issue.

@shykes

This comment has been minimized.

Show comment
Hide comment
@shykes

shykes Apr 10, 2013

Collaborator

On Wed, Apr 10, 2013 at 2:34 PM, Jérôme Petazzoni
notifications@github.comwrote:

The proposal didn't require any out-of-band configuration and didn't break

repeatability of a run.

Specifying "-v=/var/lib/mysql=/mnt/mysql" doesn't "break repeatability"
more than "-p :3306".

If you don't understand why this statement is incorrect, we'll just have to
agree to disagree.

Collaborator

shykes commented Apr 10, 2013

On Wed, Apr 10, 2013 at 2:34 PM, Jérôme Petazzoni
notifications@github.comwrote:

The proposal didn't require any out-of-band configuration and didn't break

repeatability of a run.

Specifying "-v=/var/lib/mysql=/mnt/mysql" doesn't "break repeatability"
more than "-p :3306".

If you don't understand why this statement is incorrect, we'll just have to
agree to disagree.

@Taytay

This comment has been minimized.

Show comment
Hide comment
@Taytay

Taytay Apr 17, 2013

I wasn't sure whether to comment here or in issue #382, so I settled on this one.

I am excited about Docker because of it's ability to freeze an environment and repeatably and safely execute it. This is "Linux containers done right". Using Docker, I can execute code in the docker sandbox and know that it won't be able to escape to the host system. As @sa2ajj pointed out in #382, this also could make for an excellent, standardized software distribution mechanism. Want to run build tool X? Here's the Docker image. Guaranteed to work.

We all agree that data isn't always a part of the image, so there is now a concept of external volumes. However, I think that we should allow the volumes to map to arbitrary directories on the host. @shykes, I believe you are saying that you lose the repeatability of a run if the image depends upon the presence of certain resources on the host or the necessity to invoke the image in a particular way. However, I don't understand the distinction between relying on data that lives on the network and data that lives on the host disk. In the case of data that lives on the network, Docker is more than happy to let you rely upon the presence of unversioned external resources, so why not with external file system resources?

For example, let's say I write a web-log processing tool and I package it as a Docker Image. My tool takes an ftp URL as input, downloads all of the log files it finds, processes them, and uploads the results to S3. The Docker image houses the executable, but the data it processes lives outside.

But then my boss tells me to speed things up because my tool can't keep up with the log files the servers are generating. I ditch the FTP stuff and add an option to read files from a local folder instead and write them out to another folder. I deploy my Docker image to the server where the logs are being generated. However, there doesn't appear to be a way to expose the /logs folder to the Docker image as a folder. If the /logs folder were exposed over a network interface, we're within the rules of Docker Dogma. If the /logs folder is just exposed on local filesystem, we're instead forced to manually copy files into a new container before Docker can see them, a la #382. Or, I am forced to change the interface of my tool when the local file access is the most straightforward mapping from both a developer and user point of view.

An obvious, and "simple", shortcut (that folks here are pointing out) would be to allow me to mount a host directory as a directory with the Docker image. It's one less layer of abstraction between my program and its data, and it makes my life simpler. Yes, this means that I need to make sure to remember to mount the folder, but in the FTP version of the tool I need to remember to pass the FTP credentials to the application, and need to make sure that the FTP server is reachable from the Docker container, etc. There is already unversioned, external configuration taking place if data ever lives outside of the image, whether it lives on the network or the file system.

I should mention that Picloud solves this issue elegantly, using a syntax similar to the ones proposed here. I'm able to tell Picloud to run an arbitrary command on my pre-configured Picloud environment (the equivalent of a Docker image), and tell it which volumes to mount before it does so. Yes, if I don't mount the external volume first, my program might fail, but the flexibility and simplicity of such a model more than makes up for the risk.

Taytay commented Apr 17, 2013

I wasn't sure whether to comment here or in issue #382, so I settled on this one.

I am excited about Docker because of it's ability to freeze an environment and repeatably and safely execute it. This is "Linux containers done right". Using Docker, I can execute code in the docker sandbox and know that it won't be able to escape to the host system. As @sa2ajj pointed out in #382, this also could make for an excellent, standardized software distribution mechanism. Want to run build tool X? Here's the Docker image. Guaranteed to work.

We all agree that data isn't always a part of the image, so there is now a concept of external volumes. However, I think that we should allow the volumes to map to arbitrary directories on the host. @shykes, I believe you are saying that you lose the repeatability of a run if the image depends upon the presence of certain resources on the host or the necessity to invoke the image in a particular way. However, I don't understand the distinction between relying on data that lives on the network and data that lives on the host disk. In the case of data that lives on the network, Docker is more than happy to let you rely upon the presence of unversioned external resources, so why not with external file system resources?

For example, let's say I write a web-log processing tool and I package it as a Docker Image. My tool takes an ftp URL as input, downloads all of the log files it finds, processes them, and uploads the results to S3. The Docker image houses the executable, but the data it processes lives outside.

But then my boss tells me to speed things up because my tool can't keep up with the log files the servers are generating. I ditch the FTP stuff and add an option to read files from a local folder instead and write them out to another folder. I deploy my Docker image to the server where the logs are being generated. However, there doesn't appear to be a way to expose the /logs folder to the Docker image as a folder. If the /logs folder were exposed over a network interface, we're within the rules of Docker Dogma. If the /logs folder is just exposed on local filesystem, we're instead forced to manually copy files into a new container before Docker can see them, a la #382. Or, I am forced to change the interface of my tool when the local file access is the most straightforward mapping from both a developer and user point of view.

An obvious, and "simple", shortcut (that folks here are pointing out) would be to allow me to mount a host directory as a directory with the Docker image. It's one less layer of abstraction between my program and its data, and it makes my life simpler. Yes, this means that I need to make sure to remember to mount the folder, but in the FTP version of the tool I need to remember to pass the FTP credentials to the application, and need to make sure that the FTP server is reachable from the Docker container, etc. There is already unversioned, external configuration taking place if data ever lives outside of the image, whether it lives on the network or the file system.

I should mention that Picloud solves this issue elegantly, using a syntax similar to the ones proposed here. I'm able to tell Picloud to run an arbitrary command on my pre-configured Picloud environment (the equivalent of a Docker image), and tell it which volumes to mount before it does so. Yes, if I don't mount the external volume first, my program might fail, but the flexibility and simplicity of such a model more than makes up for the risk.

@shykes

This comment has been minimized.

Show comment
Hide comment
@shykes

shykes Apr 17, 2013

Collaborator

Thanks taylor for the elaborate argument.

I think there's something to be figured out here that will satisfy
everyone.. We're already 90% there. We're close, I can feel it!

Let me noodle on this.

On Tuesday, April 16, 2013, Taylor Brown wrote:

I wasn't sure whether to comment here or in issue #382#382,
so I settled on this one.

I am excited about Docker because of it's ability to freeze an environment
and repeatably and safely execute it. This is "Linux containers done
right". Using Docker, I can execute code in the docker sandbox and know
that it won't be able to escape to the host system. As @sa2ajjhttps://github.com/sa2ajjpointed out in
#382 #382, this also could
make for an excellent, standardized software distribution mechanism. Want
to run build tool X? Here's the Docker image. Guaranteed to work.

We all agree that data isn't always a part of the image, so there is now a
concept of external volumes. However, I think that we should allow the
volumes to map to arbitrary directories on the host. @shykeshttps://github.com/shykes,
I believe you are saying that you lose the repeatability of a run if the
image depends upon the presence of certain resources on the host or the
necessity to invoke the image in a particular way. However, I don't
understand the distinction between relying on data that lives on the
network and data that lives on the host disk. In the case of data that
lives on the network, Docker is more than happy to let you rely upon the
presence of unversioned external resources, so why not with external file
system resources?

For example, let's say I write a web-log processing tool and I package it
as a Docker Image. My tool takes an ftp URL as input, downloads all of the
log files it finds, processes them, and uploads the results to S3. The
Docker image houses the executable, but the data it processes lives
outside.

But then my boss tells me to speed things up because my tool can't keep up
with the log files the servers are generating. I ditch the FTP stuff and
add an option to read files from a local folder instead and write them out
to another folder. I deploy my Docker image to the server where the logs
are being generated. However, there doesn't appear to be a way to expose
the /logs folder to the Docker image as a folder. If the /logs folder were
exposed over a network interface, we're within the rules of Docker Dogma.
If the /logs folder is just exposed on local filesystem, we're instead
forced to manually copy files into a new container before Docker can see
them, a la #382 #382. Or, I am
forced to change the interface of my tool when the local file access is the
most straightforward mapping from both a developer and user point of view.

An obvious, and "simple", shortcut (that folks here are pointing out)
would be to allow me to mount a host directory as a directory with the
Docker image. It's one less layer of abstraction between my program and its
data, and it makes my life simpler. Yes, this means that I need to make
sure to remember to mount the folder, but in the FTP version of the tool I
need to remember to pass the FTP credentials to the application, and need
to make sure that the FTP server is reachable from the Docker container,
etc. There is already unversioned, external configuration taking place if
data ever lives outside of the image, whether it lives on the network or
the file system.

I should mention that Picloud solves this issue elegantlyhttp://docs.picloud.com/volume.html,
using a syntax similar to the ones proposed here. I'm able to tell Picloud
to run an arbitrary command on my pre-configured Picloud environment (the
equivalent of a Docker image), and tell it which volumes to mount before it
does so. Yes, if I don't mount the external volume first, my program might
fail, but the flexibility and simplicity of such a model more than makes up
for the risk.


Reply to this email directly or view it on GitHubhttps://github.com/dotcloud/docker/issues/111#issuecomment-16487713
.

Collaborator

shykes commented Apr 17, 2013

Thanks taylor for the elaborate argument.

I think there's something to be figured out here that will satisfy
everyone.. We're already 90% there. We're close, I can feel it!

Let me noodle on this.

On Tuesday, April 16, 2013, Taylor Brown wrote:

I wasn't sure whether to comment here or in issue #382#382,
so I settled on this one.

I am excited about Docker because of it's ability to freeze an environment
and repeatably and safely execute it. This is "Linux containers done
right". Using Docker, I can execute code in the docker sandbox and know
that it won't be able to escape to the host system. As @sa2ajjhttps://github.com/sa2ajjpointed out in
#382 #382, this also could
make for an excellent, standardized software distribution mechanism. Want
to run build tool X? Here's the Docker image. Guaranteed to work.

We all agree that data isn't always a part of the image, so there is now a
concept of external volumes. However, I think that we should allow the
volumes to map to arbitrary directories on the host. @shykeshttps://github.com/shykes,
I believe you are saying that you lose the repeatability of a run if the
image depends upon the presence of certain resources on the host or the
necessity to invoke the image in a particular way. However, I don't
understand the distinction between relying on data that lives on the
network and data that lives on the host disk. In the case of data that
lives on the network, Docker is more than happy to let you rely upon the
presence of unversioned external resources, so why not with external file
system resources?

For example, let's say I write a web-log processing tool and I package it
as a Docker Image. My tool takes an ftp URL as input, downloads all of the
log files it finds, processes them, and uploads the results to S3. The
Docker image houses the executable, but the data it processes lives
outside.

But then my boss tells me to speed things up because my tool can't keep up
with the log files the servers are generating. I ditch the FTP stuff and
add an option to read files from a local folder instead and write them out
to another folder. I deploy my Docker image to the server where the logs
are being generated. However, there doesn't appear to be a way to expose
the /logs folder to the Docker image as a folder. If the /logs folder were
exposed over a network interface, we're within the rules of Docker Dogma.
If the /logs folder is just exposed on local filesystem, we're instead
forced to manually copy files into a new container before Docker can see
them, a la #382 #382. Or, I am
forced to change the interface of my tool when the local file access is the
most straightforward mapping from both a developer and user point of view.

An obvious, and "simple", shortcut (that folks here are pointing out)
would be to allow me to mount a host directory as a directory with the
Docker image. It's one less layer of abstraction between my program and its
data, and it makes my life simpler. Yes, this means that I need to make
sure to remember to mount the folder, but in the FTP version of the tool I
need to remember to pass the FTP credentials to the application, and need
to make sure that the FTP server is reachable from the Docker container,
etc. There is already unversioned, external configuration taking place if
data ever lives outside of the image, whether it lives on the network or
the file system.

I should mention that Picloud solves this issue elegantlyhttp://docs.picloud.com/volume.html,
using a syntax similar to the ones proposed here. I'm able to tell Picloud
to run an arbitrary command on my pre-configured Picloud environment (the
equivalent of a Docker image), and tell it which volumes to mount before it
does so. Yes, if I don't mount the external volume first, my program might
fail, but the flexibility and simplicity of such a model more than makes up
for the risk.


Reply to this email directly or view it on GitHubhttps://github.com/dotcloud/docker/issues/111#issuecomment-16487713
.

@Taytay

This comment has been minimized.

Show comment
Hide comment
@Taytay

Taytay Apr 17, 2013

Thanks for the quick response @shykes. I appreciate your thoughtfulness with Docker, and the desire to get it right, especially since we're in the formative days of something we all know will be big. :)

Taytay commented Apr 17, 2013

Thanks for the quick response @shykes. I appreciate your thoughtfulness with Docker, and the desire to get it right, especially since we're in the formative days of something we all know will be big. :)

@DanielVF

This comment has been minimized.

Show comment
Hide comment
@DanielVF

DanielVF Apr 18, 2013

Contributor

For my use case, I have customers who upload and modify files. I then have a server process in a container that serves up a processed view up whatever is currently in those files. To perform software upgrades, I want to be able to start up a new server container with the latest code, but the same data directory, then shut down the old container.

Contributor

DanielVF commented Apr 18, 2013

For my use case, I have customers who upload and modify files. I then have a server process in a container that serves up a processed view up whatever is currently in those files. To perform software upgrades, I want to be able to start up a new server container with the latest code, but the same data directory, then shut down the old container.

@shykes

This comment has been minimized.

Show comment
Hide comment
@shykes

shykes Apr 18, 2013

Collaborator

Hi Daniel, in the current implementation (
#376) this should already work :)
See below for an example:

V1=$(docker run -d -v /data danielvf/myapp:1.0 runapp)
V2=$(docker run -d -volumes-from $V1 danielvf/myapp:2.0 runapp)
# Test that v2 is reachable, this is outside the scope of docker
docker stop $V1

Note that the pull request is still under review, but if you build it, the
above example will actually work.

On Thu, Apr 18, 2013 at 11:15 AM, DanielVF notifications@github.com wrote:

For my use case, I have customers who upload and modify files. I then have
a server process in a container that serves up a processed view up whatever
is currently in those files. To perform software upgrades, I want to be
able to start up a new server container with the latest code, but the same
data directory, then shut down the old container.


Reply to this email directly or view it on GitHubhttps://github.com/dotcloud/docker/issues/111#issuecomment-16593708
.

Collaborator

shykes commented Apr 18, 2013

Hi Daniel, in the current implementation (
#376) this should already work :)
See below for an example:

V1=$(docker run -d -v /data danielvf/myapp:1.0 runapp)
V2=$(docker run -d -volumes-from $V1 danielvf/myapp:2.0 runapp)
# Test that v2 is reachable, this is outside the scope of docker
docker stop $V1

Note that the pull request is still under review, but if you build it, the
above example will actually work.

On Thu, Apr 18, 2013 at 11:15 AM, DanielVF notifications@github.com wrote:

For my use case, I have customers who upload and modify files. I then have
a server process in a container that serves up a processed view up whatever
is currently in those files. To perform software upgrades, I want to be
able to start up a new server container with the latest code, but the same
data directory, then shut down the old container.


Reply to this email directly or view it on GitHubhttps://github.com/dotcloud/docker/issues/111#issuecomment-16593708
.

@DanielVF

This comment has been minimized.

Show comment
Hide comment
@DanielVF

DanielVF Apr 18, 2013

Contributor

Thanks @shykes. I will play with that branch.

Contributor

DanielVF commented Apr 18, 2013

Thanks @shykes. I will play with that branch.

@neomantra

This comment has been minimized.

Show comment
Hide comment
@neomantra

neomantra Apr 24, 2013

Contributor

Another use case for exposing the host file system is for communication via Unix Domain Sockets and mqueues, which use files as the connection point. Or maybe also exposing serial ports in /dev?

The original proposal at the top of this thread would allow this, however, I don't think the "data volumes" spec covers it since it only deals with container-to-container bridging and extraction.

This is concept definitely opposed to @shykes comment regarding repeatability on different hosts. Similarly, what I tried to do here with pinning CPUs (#439) is host-specific, albeit repeatable only if different hosts supports all the same key/values. But people who do this would be using some way of configuring/maintaining it all (like picking service endpoints filepaths/host:port or making sure all processes aren't pinned to the same CPU).

Contributor

neomantra commented Apr 24, 2013

Another use case for exposing the host file system is for communication via Unix Domain Sockets and mqueues, which use files as the connection point. Or maybe also exposing serial ports in /dev?

The original proposal at the top of this thread would allow this, however, I don't think the "data volumes" spec covers it since it only deals with container-to-container bridging and extraction.

This is concept definitely opposed to @shykes comment regarding repeatability on different hosts. Similarly, what I tried to do here with pinning CPUs (#439) is host-specific, albeit repeatable only if different hosts supports all the same key/values. But people who do this would be using some way of configuring/maintaining it all (like picking service endpoints filepaths/host:port or making sure all processes aren't pinned to the same CPU).

@jpetazzo

This comment has been minimized.

Show comment
Hide comment
@jpetazzo

jpetazzo Apr 24, 2013

Contributor

I had an interesting discussion with @mpetazzoni yesterday about a rather
contrived use-case: using containerization to provide isolated environment
for remote shell access on a multi-user server.

Specifically, the concern was to operate the local MTA in a separate
container, but still deliver mails to e.g. ~/Maildir (per-user).

The challenge here is "partial volume sharing", i.e. the "shell" containers
should be given access only to /home/$USERNAME (for a unique $USERNAME),
while the MTA should be able to access /home/$USERNAME/Maildir (for all
users of the system).

On Wed, Apr 24, 2013 at 3:49 PM, Evan notifications@github.com wrote:

Another use case for exposing the host file system is for communication
via Unix Domain Sockets, mqueues, , all which use files as the connection
point. Or maybe also exposing serial ports in /dev?

The original proposal at the top of this thread would allow this, however,
I don't think the "data volumes" spec covers it since it only deals with
container-to-container bridging and extraction.

This is concept definitely opposed to @shykes https://github.com/shykescomment regarding repeatability on different hosts. Similarly, what I tried
to do here with pinning CPUs (#439#439)
is host-specific, albeit repeatable only if different hosts supports all
the same key/values. But people who do this would be using some way of
configuring/maintaining it all (like picking service endpoints
filepaths/host:port or making sure all processes aren't pinned to the same
CPU).


Reply to this email directly or view it on GitHubhttps://github.com/dotcloud/docker/issues/111#issuecomment-16977366
.

Contributor

jpetazzo commented Apr 24, 2013

I had an interesting discussion with @mpetazzoni yesterday about a rather
contrived use-case: using containerization to provide isolated environment
for remote shell access on a multi-user server.

Specifically, the concern was to operate the local MTA in a separate
container, but still deliver mails to e.g. ~/Maildir (per-user).

The challenge here is "partial volume sharing", i.e. the "shell" containers
should be given access only to /home/$USERNAME (for a unique $USERNAME),
while the MTA should be able to access /home/$USERNAME/Maildir (for all
users of the system).

On Wed, Apr 24, 2013 at 3:49 PM, Evan notifications@github.com wrote:

Another use case for exposing the host file system is for communication
via Unix Domain Sockets, mqueues, , all which use files as the connection
point. Or maybe also exposing serial ports in /dev?

The original proposal at the top of this thread would allow this, however,
I don't think the "data volumes" spec covers it since it only deals with
container-to-container bridging and extraction.

This is concept definitely opposed to @shykes https://github.com/shykescomment regarding repeatability on different hosts. Similarly, what I tried
to do here with pinning CPUs (#439#439)
is host-specific, albeit repeatable only if different hosts supports all
the same key/values. But people who do this would be using some way of
configuring/maintaining it all (like picking service endpoints
filepaths/host:port or making sure all processes aren't pinned to the same
CPU).


Reply to this email directly or view it on GitHubhttps://github.com/dotcloud/docker/issues/111#issuecomment-16977366
.

@shykes

This comment has been minimized.

Show comment
Hide comment
@shykes

shykes Apr 24, 2013

Collaborator

So, I now have enough datapoints (ie people yelling at me) to acknowledge the need for "choosing your own adventure" when it comes to custom runtime configuration: cpu pinning, external mountpoints, etc.

So, to quote @brianm, we need "escape hatches" for the experts without ruining the experience for everyone.

To get back to external mountpoints for volumes, I am convinced and have a design in mind for the escape hatch, stay tuned.

@solomonstre
@getdocker

On Wed, Apr 24, 2013 at 3:49 PM, Evan notifications@github.com wrote:

Another use case for exposing the host file system is for communication via Unix Domain Sockets, mqueues, , all which use files as the connection point. Or maybe also exposing serial ports in /dev?
The original proposal at the top of this thread would allow this, however, I don't think the "data volumes" spec covers it since it only deals with container-to-container bridging and extraction.

This is concept definitely opposed to @shykes comment regarding repeatability on different hosts. Similarly, what I tried to do here with pinning CPUs (#439) is host-specific, albeit repeatable only if different hosts supports all the same key/values. But people who do this would be using some way of configuring/maintaining it all (like picking service endpoints filepaths/host:port or making sure all processes aren't pinned to the same CPU).

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

Collaborator

shykes commented Apr 24, 2013

So, I now have enough datapoints (ie people yelling at me) to acknowledge the need for "choosing your own adventure" when it comes to custom runtime configuration: cpu pinning, external mountpoints, etc.

So, to quote @brianm, we need "escape hatches" for the experts without ruining the experience for everyone.

To get back to external mountpoints for volumes, I am convinced and have a design in mind for the escape hatch, stay tuned.

@solomonstre
@getdocker

On Wed, Apr 24, 2013 at 3:49 PM, Evan notifications@github.com wrote:

Another use case for exposing the host file system is for communication via Unix Domain Sockets, mqueues, , all which use files as the connection point. Or maybe also exposing serial ports in /dev?
The original proposal at the top of this thread would allow this, however, I don't think the "data volumes" spec covers it since it only deals with container-to-container bridging and extraction.

This is concept definitely opposed to @shykes comment regarding repeatability on different hosts. Similarly, what I tried to do here with pinning CPUs (#439) is host-specific, albeit repeatable only if different hosts supports all the same key/values. But people who do this would be using some way of configuring/maintaining it all (like picking service endpoints filepaths/host:port or making sure all processes aren't pinned to the same CPU).

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

@shykes

This comment has been minimized.

Show comment
Hide comment
@shykes

shykes Apr 24, 2013

Collaborator

.. and the design will solve your MTA example, jerome, as well as all those listed in this issue.

@solomonstre
@getdocker

On Wed, Apr 24, 2013 at 4:16 PM, Jérôme Petazzoni
notifications@github.com wrote:

I had an interesting discussion with @mpetazzoni yesterday about a rather
contrived use-case: using containerization to provide isolated environment
for remote shell access on a multi-user server.
Specifically, the concern was to operate the local MTA in a separate
container, but still deliver mails to e.g. ~/Maildir (per-user).
The challenge here is "partial volume sharing", i.e. the "shell" containers
should be given access only to /home/$USERNAME (for a unique $USERNAME),
while the MTA should be able to access /home/$USERNAME/Maildir (for all
users of the system).
On Wed, Apr 24, 2013 at 3:49 PM, Evan notifications@github.com wrote:

Another use case for exposing the host file system is for communication
via Unix Domain Sockets, mqueues, , all which use files as the connection
point. Or maybe also exposing serial ports in /dev?

The original proposal at the top of this thread would allow this, however,
I don't think the "data volumes" spec covers it since it only deals with
container-to-container bridging and extraction.

This is concept definitely opposed to @shykes https://github.com/shykescomment regarding repeatability on different hosts. Similarly, what I tried
to do here with pinning CPUs (#439#439)
is host-specific, albeit repeatable only if different hosts supports all
the same key/values. But people who do this would be using some way of
configuring/maintaining it all (like picking service endpoints
filepaths/host:port or making sure all processes aren't pinned to the same
CPU).


Reply to this email directly or view it on GitHubhttps://github.com/dotcloud/docker/issues/111#issuecomment-16977366
.


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

Collaborator

shykes commented Apr 24, 2013

.. and the design will solve your MTA example, jerome, as well as all those listed in this issue.

@solomonstre
@getdocker

On Wed, Apr 24, 2013 at 4:16 PM, Jérôme Petazzoni
notifications@github.com wrote:

I had an interesting discussion with @mpetazzoni yesterday about a rather
contrived use-case: using containerization to provide isolated environment
for remote shell access on a multi-user server.
Specifically, the concern was to operate the local MTA in a separate
container, but still deliver mails to e.g. ~/Maildir (per-user).
The challenge here is "partial volume sharing", i.e. the "shell" containers
should be given access only to /home/$USERNAME (for a unique $USERNAME),
while the MTA should be able to access /home/$USERNAME/Maildir (for all
users of the system).
On Wed, Apr 24, 2013 at 3:49 PM, Evan notifications@github.com wrote:

Another use case for exposing the host file system is for communication
via Unix Domain Sockets, mqueues, , all which use files as the connection
point. Or maybe also exposing serial ports in /dev?

The original proposal at the top of this thread would allow this, however,
I don't think the "data volumes" spec covers it since it only deals with
container-to-container bridging and extraction.

This is concept definitely opposed to @shykes https://github.com/shykescomment regarding repeatability on different hosts. Similarly, what I tried
to do here with pinning CPUs (#439#439)
is host-specific, albeit repeatable only if different hosts supports all
the same key/values. But people who do this would be using some way of
configuring/maintaining it all (like picking service endpoints
filepaths/host:port or making sure all processes aren't pinned to the same
CPU).


Reply to this email directly or view it on GitHubhttps://github.com/dotcloud/docker/issues/111#issuecomment-16977366
.


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

@creack

This comment has been minimized.

Show comment
Hide comment
@creack

creack May 7, 2013

Contributor

Closed by #376

Contributor

creack commented May 7, 2013

Closed by #376

@creack creack closed this May 7, 2013

@niclashoyer

This comment has been minimized.

Show comment
Hide comment
@niclashoyer

niclashoyer May 7, 2013

does the pull request #376 solve the use cases mentioned here? If so, is there any documentation about how to use it?

does the pull request #376 solve the use cases mentioned here? If so, is there any documentation about how to use it?

@ptone ptone referenced this issue in ptone/jiffylab Jun 26, 2013

Open

setup lab-wide shared folder #12

@Kloadut Kloadut referenced this issue in dokku/dokku Aug 13, 2013

Closed

PostgreSQL plugin #166

@jpetazzo jpetazzo referenced this issue Jul 4, 2014

Closed

Collected issues with Volumes #6496

7 of 12 tasks complete

erikh added a commit to erikh/docker that referenced this issue Dec 4, 2014

runcom pushed a commit to runcom/docker that referenced this issue Apr 20, 2016

ijc added a commit to ijc/moby that referenced this issue Jan 31, 2017

Revendor github.com/spf13/pflag to 9ff6c6923cfffbcd502984b8e0c80539a9…
…4968b7

This pulls in the change made in my fork as 9ff6c6923cff:

$ git log --oneline ca3be74b3ca72..9ff6c6923cff
9ff6c69 Add FlagSet.FlagUsagesWrapped(cols) which wraps to the given column (#105)
a9a634f Add BoolSlice and UintSlice flag types. (#111)
a232f6d Merge pull request #102 from bogem/redundant
5126803 Merge pull request #110 from hardikbagdi/master
230dccf add badges to README.md
c431975 Merge pull request #107 from xilabao/add-user-supplied-func-when-parse
271ea0e Make command line parsing available outside pflag
25f8b5b Merge pull request #109 from SinghamXiao/master
1fcda0c too many arguments
86d3545 Clean up code

Signed-off-by: Ian Campbell <ian.campbell@docker.com>

ijc added a commit to ijc/moby that referenced this issue Jan 31, 2017

Revendor github.com/spf13/pflag to 9ff6c6923cfffbcd502984b8e0c80539a9…
…4968b7

This pulls in the change made in my fork as 9ff6c6923cff:

$ git log --oneline ca3be74b3ca72..9ff6c6923cff
9ff6c69 Add FlagSet.FlagUsagesWrapped(cols) which wraps to the given column (#105)
a9a634f Add BoolSlice and UintSlice flag types. (#111)
a232f6d Merge pull request #102 from bogem/redundant
5126803 Merge pull request #110 from hardikbagdi/master
230dccf add badges to README.md
c431975 Merge pull request #107 from xilabao/add-user-supplied-func-when-parse
271ea0e Make command line parsing available outside pflag
25f8b5b Merge pull request #109 from SinghamXiao/master
1fcda0c too many arguments
86d3545 Clean up code

Signed-off-by: Ian Campbell <ian.campbell@docker.com>

ijc added a commit to ijc/moby that referenced this issue Feb 1, 2017

Revendor github.com/spf13/pflag to 9ff6c6923cfffbcd502984b8e0c80539a9…
…4968b7

$ git log --oneline dabebe21bf79..9ff6c6923cff
9ff6c69 Add FlagSet.FlagUsagesWrapped(cols) which wraps to the given column (#105)
a9a634f Add BoolSlice and UintSlice flag types. (#111)
a232f6d Merge pull request #102 from bogem/redundant
5126803 Merge pull request #110 from hardikbagdi/master
230dccf add badges to README.md
c431975 Merge pull request #107 from xilabao/add-user-supplied-func-when-parse
271ea0e Make command line parsing available outside pflag
25f8b5b Merge pull request #109 from SinghamXiao/master
1fcda0c too many arguments
5ccb023 Remove Go 1.5 from Travis
86d3545 Clean up code

I am interested in 9ff6c69 for a followup.

Signed-off-by: Ian Campbell <ian.campbell@docker.com>

ijc added a commit to ijc/moby that referenced this issue Feb 3, 2017

Revendor github.com/spf13/pflag to 9ff6c6923cfffbcd502984b8e0c80539a9…
…4968b7

$ git log --oneline dabebe21bf79..9ff6c6923cff
9ff6c69 Add FlagSet.FlagUsagesWrapped(cols) which wraps to the given column (#105)
a9a634f Add BoolSlice and UintSlice flag types. (#111)
a232f6d Merge pull request #102 from bogem/redundant
5126803 Merge pull request #110 from hardikbagdi/master
230dccf add badges to README.md
c431975 Merge pull request #107 from xilabao/add-user-supplied-func-when-parse
271ea0e Make command line parsing available outside pflag
25f8b5b Merge pull request #109 from SinghamXiao/master
1fcda0c too many arguments
5ccb023 Remove Go 1.5 from Travis
86d3545 Clean up code

I am interested in 9ff6c69 for a followup.

Signed-off-by: Ian Campbell <ian.campbell@docker.com>

srust added a commit to srust/moby that referenced this issue Nov 30, 2017

Revendor github.com/spf13/pflag to 9ff6c6923cfffbcd502984b8e0c80539a9…
…4968b7

$ git log --oneline dabebe21bf79..9ff6c6923cff
9ff6c69 Add FlagSet.FlagUsagesWrapped(cols) which wraps to the given column (#105)
a9a634f Add BoolSlice and UintSlice flag types. (#111)
a232f6d Merge pull request #102 from bogem/redundant
5126803 Merge pull request #110 from hardikbagdi/master
230dccf add badges to README.md
c431975 Merge pull request #107 from xilabao/add-user-supplied-func-when-parse
271ea0e Make command line parsing available outside pflag
25f8b5b Merge pull request #109 from SinghamXiao/master
1fcda0c too many arguments
5ccb023 Remove Go 1.5 from Travis
86d3545 Clean up code

I am interested in 9ff6c69 for a followup.

Signed-off-by: Ian Campbell <ian.campbell@docker.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment