New issue

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

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Proposal: Add volume ls/inspect/rm/create commands #8484

Closed
wants to merge 2 commits into
base: master
from

Conversation

Projects
None yet
@cpuguy83
Contributor

cpuguy83 commented Oct 9, 2014

docker volumes ls - list all volumes
Can be used with --filter dangling=true to list volumes not in use

docker volumes create - create volumes
Can set, --name, --path, --mode. Can also be used with no
arguments to have everything auto generated

docker volumes rm <volume name> - Remove a volume
Volumes in use by containers cannot be removed.
Bind-mounts cannot be removed. (May want to have a way to remove just
the bind-mount config. Else this does seem to cause issues with tests)

docker volumes inspect <volume name> - Inspect a volume/get its config
Supports --format just like container inspect.

docker run can be used to either call a volume by name as docker run -v <volume name>:<mount point> or with docker run --volumes-from <volume alias>:<mount point>[:<mode>]
docker run -v <path> will create a volume with a generated name, just
as docker volumes create with no args.

All existing APIs/UI will work as normal.
There is no breakage in these changes.

Implements Proposal #8363

@vieux

This comment has been minimized.

Show comment
Hide comment
@vieux

vieux Oct 9, 2014

Collaborator

@cpuguy83 what is the default path for docker volumes create ?

Collaborator

vieux commented Oct 9, 2014

@cpuguy83 what is the default path for docker volumes create ?

@cpuguy83

This comment has been minimized.

Show comment
Hide comment
@cpuguy83

cpuguy83 Oct 9, 2014

Contributor

Same as creating a volume through "run -v", so /var/lib/docker/vfs/dir/<id>

Contributor

cpuguy83 commented Oct 9, 2014

Same as creating a volume through "run -v", so /var/lib/docker/vfs/dir/<id>

@vieux

This comment has been minimized.

Show comment
Hide comment
@vieux

vieux Oct 9, 2014

Collaborator

@cpuguy83 oh thanks I didn't remebeer we changed this

Collaborator

vieux commented Oct 9, 2014

@cpuguy83 oh thanks I didn't remebeer we changed this

@cpuguy83

This comment has been minimized.

Show comment
Hide comment
@cpuguy83

cpuguy83 Oct 14, 2014

Contributor

@vieux That's actually not changed, or at least not changed in quite some time.

Contributor

cpuguy83 commented Oct 14, 2014

@vieux That's actually not changed, or at least not changed in quite some time.

@zhgwenming

This comment has been minimized.

Show comment
Hide comment
@zhgwenming

zhgwenming Oct 21, 2014

Contributor

@cpuguy83 this is cool.
Maybe use 'volume' instead of 'volumes' would be better?

Contributor

zhgwenming commented Oct 21, 2014

@cpuguy83 this is cool.
Maybe use 'volume' instead of 'volumes' would be better?

@cpuguy83

This comment has been minimized.

Show comment
Hide comment
@cpuguy83

cpuguy83 Oct 21, 2014

Contributor

@zhgwenming Not really, because we are dealing with a collection of volumes.

Contributor

cpuguy83 commented Oct 21, 2014

@zhgwenming Not really, because we are dealing with a collection of volumes.

@cpuguy83 cpuguy83 referenced this pull request Oct 22, 2014

Closed

Colons in pathnames #8604

@mbreese

This comment has been minimized.

Show comment
Hide comment
@mbreese

mbreese Oct 22, 2014

I'd vote for using the singular, as in "docker volume" instead of "volumes". Most of the operations are on an individual volume, except "ls".

(It's the same argument for why some people name database tables as plural vs. singluar)

I'd actually prefer to have multiple top-level commands like "vol-create", "vol-delete", "vol-list", "vol-inspect", but that maybe too much like virsh for your liking.

mbreese commented Oct 22, 2014

I'd vote for using the singular, as in "docker volume" instead of "volumes". Most of the operations are on an individual volume, except "ls".

(It's the same argument for why some people name database tables as plural vs. singluar)

I'd actually prefer to have multiple top-level commands like "vol-create", "vol-delete", "vol-list", "vol-inspect", but that maybe too much like virsh for your liking.

@tsutsu

This comment has been minimized.

Show comment
Hide comment
@tsutsu

tsutsu Oct 23, 2014

I would expect docker volumes rm to have Unix unlink(2) semantics: dropping the ref from Docker itself to the volume (making it disappear from the list, and making nothing new able to link to it) but having the underlying store stick around until the last container using it is removed, at which point it gets removed automatically as well.

tsutsu commented Oct 23, 2014

I would expect docker volumes rm to have Unix unlink(2) semantics: dropping the ref from Docker itself to the volume (making it disappear from the list, and making nothing new able to link to it) but having the underlying store stick around until the last container using it is removed, at which point it gets removed automatically as well.

@cpuguy83

This comment has been minimized.

Show comment
Hide comment
@cpuguy83

cpuguy83 Oct 23, 2014

Contributor

@tsutsu I sort of like the idea, but also feel it is somewhat surprising behavior. I think it falls into the realm of GC, which Docker does not handle itself at all right now.
I would prefer to keep things as simple as possible to start and if/when Docker implements a GC concept it can be applied to volumes.

Contributor

cpuguy83 commented Oct 23, 2014

@tsutsu I sort of like the idea, but also feel it is somewhat surprising behavior. I think it falls into the realm of GC, which Docker does not handle itself at all right now.
I would prefer to keep things as simple as possible to start and if/when Docker implements a GC concept it can be applied to volumes.

@pchico83

This comment has been minimized.

Show comment
Hide comment
@pchico83

pchico83 Oct 28, 2014

@cpuguy83 Could we have, as part of the information returned by "docker volumes inspect <volume_name>", the containers that are using this volume?

pchico83 commented Oct 28, 2014

@cpuguy83 Could we have, as part of the information returned by "docker volumes inspect <volume_name>", the containers that are using this volume?

@cpuguy83

This comment has been minimized.

Show comment
Hide comment
@cpuguy83

cpuguy83 Oct 28, 2014

Contributor

@pchoco83 already there.

Contributor

cpuguy83 commented Oct 28, 2014

@pchoco83 already there.

@pchico83

This comment has been minimized.

Show comment
Hide comment
@pchico83

pchico83 Oct 28, 2014

@cpuguy83 I just saw the "Aliases" info, thanks!

pchico83 commented Oct 28, 2014

@cpuguy83 I just saw the "Aliases" info, thanks!

@pchico83

This comment has been minimized.

Show comment
Hide comment
@pchico83

pchico83 Oct 28, 2014

@cpuguy83 I compiled the docker binary from this branch in order to play with it.
I am not able to use "--volumes-from" from an existing volume:

#docker volumes inspect test-volume
[{
"Aliases": null,
"Created": "2014-10-28T18:09:22.583335347Z",
"Id": "db644ac06fc8e51de1bf433bb1bd5539805d6e2f6796946e7adc726cb5729158",
"IsBindMount": false,
"Name": "test-volume",
"Path": "/var/lib/docker/vfs/dir/db644ac06fc8e51.....946e7adc726cb5729158",
"Writable": true
}]

#docker run -d -P --volumes-from test-volume:/etc/mysql tutum/mysql
309aa2bdbaea256a2bd7e594f4d6caa5f3065725cd2f307b960fdcc13794a15c
[2014-10-28T18:16:13.680404629Z] [fatal] log.go:64 Error response from daemon: Cannot start container 309aa2bdbaea256a2bd7e594f4d6caa5f3065725cd2f307b960fdcc13794a15c: Container test-volume not found. Impossible to mount its volumes

Is this option not implemented yet?

pchico83 commented Oct 28, 2014

@cpuguy83 I compiled the docker binary from this branch in order to play with it.
I am not able to use "--volumes-from" from an existing volume:

#docker volumes inspect test-volume
[{
"Aliases": null,
"Created": "2014-10-28T18:09:22.583335347Z",
"Id": "db644ac06fc8e51de1bf433bb1bd5539805d6e2f6796946e7adc726cb5729158",
"IsBindMount": false,
"Name": "test-volume",
"Path": "/var/lib/docker/vfs/dir/db644ac06fc8e51.....946e7adc726cb5729158",
"Writable": true
}]

#docker run -d -P --volumes-from test-volume:/etc/mysql tutum/mysql
309aa2bdbaea256a2bd7e594f4d6caa5f3065725cd2f307b960fdcc13794a15c
[2014-10-28T18:16:13.680404629Z] [fatal] log.go:64 Error response from daemon: Cannot start container 309aa2bdbaea256a2bd7e594f4d6caa5f3065725cd2f307b960fdcc13794a15c: Container test-volume not found. Impossible to mount its volumes

Is this option not implemented yet?

@pchico83

This comment has been minimized.

Show comment
Hide comment
@pchico83

pchico83 Oct 28, 2014

@cpuguy83 I realized it works if using a "volume_alias" instead of the "volume_name".
I think it would be more usable if using "volume_name", thoughts?
Also, if the container that creates the alias is removed, the corresponding alias in the volume is gone and the volume becomes unusable.

pchico83 commented Oct 28, 2014

@cpuguy83 I realized it works if using a "volume_alias" instead of the "volume_name".
I think it would be more usable if using "volume_name", thoughts?
Also, if the container that creates the alias is removed, the corresponding alias in the volume is gone and the volume becomes unusable.

@cpuguy83

This comment has been minimized.

Show comment
Hide comment
@cpuguy83

cpuguy83 Oct 28, 2014

Contributor

@pchico83 No. --volumes-from is still the same basic behavior, except that now instead of grabbing all volumes from a container, you can grab just a single one, and have a custom mount point.
A volume alias is just a container name + volume mount path.

You can, however, use the name with -v.

Contributor

cpuguy83 commented Oct 28, 2014

@pchico83 No. --volumes-from is still the same basic behavior, except that now instead of grabbing all volumes from a container, you can grab just a single one, and have a custom mount point.
A volume alias is just a container name + volume mount path.

You can, however, use the name with -v.

@pchico83

This comment has been minimized.

Show comment
Hide comment
@pchico83

pchico83 Oct 28, 2014

@cpuguy83 Thanks! Is the "-v" option (using a volume name) available from the remote API?

pchico83 commented Oct 28, 2014

@cpuguy83 Thanks! Is the "-v" option (using a volume name) available from the remote API?

@cpuguy83

This comment has been minimized.

Show comment
Hide comment
@cpuguy83

cpuguy83 Oct 28, 2014

Contributor

@pchico83 The docker CLI only ever uses the remote API, so yes :)

Contributor

cpuguy83 commented Oct 28, 2014

@pchico83 The docker CLI only ever uses the remote API, so yes :)

@pchico83

This comment has been minimized.

Show comment
Hide comment
@pchico83

pchico83 Oct 28, 2014

@cpuguy83 Found it. Using "binds" when starting a container. Thanks!

pchico83 commented Oct 28, 2014

@cpuguy83 Found it. Using "binds" when starting a container. Thanks!

@thaJeztah

This comment has been minimized.

Show comment
Hide comment
@thaJeztah

thaJeztah Oct 28, 2014

Member

I love this PR, but have a feeling that the CLI commands are becoming inconsistent and should be reviewed to be more in line with each other, for example;

Entity Action Command Notes
Image list docker images no sub command (ls)
Container list docker ps
Volume list docker volumes ls
Links list docker links list see #7468
Image delete docker rmi (id)
Container delete docker rm (id)
Volume delete docker volumes rm (id)
Links delete docker links remove (id)

From the above list, maybe the ls subcommand should be omitted to be in line with images and be used if no subcommand is provided. Since both the "links" (#7468) and "volumes" changes are still a proposal, I think those commands should be made the same before they're implemented to keep things consistent.

For the other commands (and yes, that's out of scope for this PR) I understand that most frequently used commands are deliberately left short for convenience, perhaps "long" versions (docker images rm) should be added to make the UI more consistent?

Sorry for hijacking one of your PRs (again!) perhaps I should copy it to a separate proposal as well, lol.

Member

thaJeztah commented Oct 28, 2014

I love this PR, but have a feeling that the CLI commands are becoming inconsistent and should be reviewed to be more in line with each other, for example;

Entity Action Command Notes
Image list docker images no sub command (ls)
Container list docker ps
Volume list docker volumes ls
Links list docker links list see #7468
Image delete docker rmi (id)
Container delete docker rm (id)
Volume delete docker volumes rm (id)
Links delete docker links remove (id)

From the above list, maybe the ls subcommand should be omitted to be in line with images and be used if no subcommand is provided. Since both the "links" (#7468) and "volumes" changes are still a proposal, I think those commands should be made the same before they're implemented to keep things consistent.

For the other commands (and yes, that's out of scope for this PR) I understand that most frequently used commands are deliberately left short for convenience, perhaps "long" versions (docker images rm) should be added to make the UI more consistent?

Sorry for hijacking one of your PRs (again!) perhaps I should copy it to a separate proposal as well, lol.

@cpuguy83

This comment has been minimized.

Show comment
Hide comment
@cpuguy83

cpuguy83 Oct 29, 2014

Contributor

@thaJeztah All good.
It's something we've discussed, there's also docker hosts.

I think we unofficially decided on docker foo ls, but also have docker foo perform the ls action.
So docker volumes does the same thing as docker volumes ls

There's also the API endpoints to consider as well. They all need to be somewhat in line.

Contributor

cpuguy83 commented Oct 29, 2014

@thaJeztah All good.
It's something we've discussed, there's also docker hosts.

I think we unofficially decided on docker foo ls, but also have docker foo perform the ls action.
So docker volumes does the same thing as docker volumes ls

There's also the API endpoints to consider as well. They all need to be somewhat in line.

@thaJeztah

This comment has been minimized.

Show comment
Hide comment
@thaJeztah

thaJeztah Oct 29, 2014

Member

@cpuguy83 great! Not 100% sure If ls makes sense for all "entities"?

I did create a separate issue for the inconsistencies with the device PR mentioned as well. I missed the docker hosts command, and will add that.

All PRs mentioned are excellent additions, just trying to keep the UI consistent while it's still possible to change 😄

Member

thaJeztah commented Oct 29, 2014

@cpuguy83 great! Not 100% sure If ls makes sense for all "entities"?

I did create a separate issue for the inconsistencies with the device PR mentioned as well. I missed the docker hosts command, and will add that.

All PRs mentioned are excellent additions, just trying to keep the UI consistent while it's still possible to change 😄

@pchico83

This comment has been minimized.

Show comment
Hide comment
@pchico83

pchico83 Oct 29, 2014

@cpuguy83 I am implementing the following use case: I want to deploy an image with volumes and want to inspect the new container and its volumes (in order to build these relations in my database). These are the steps I am following:

1 - Deploy a container from an image with volumes define in the build process.
2 - Inspect the container to get its volumes.
3 - List all the volumes.
4 - Inspect each volume until I find the volumes whose (host) path match the new container volumes.

This is impractical since I need to inspect every volume. Could we have the (host) path as part of the Volume List operation? It would reduce the number of API calls a lot for this use case, which should be relatively common.

pchico83 commented Oct 29, 2014

@cpuguy83 I am implementing the following use case: I want to deploy an image with volumes and want to inspect the new container and its volumes (in order to build these relations in my database). These are the steps I am following:

1 - Deploy a container from an image with volumes define in the build process.
2 - Inspect the container to get its volumes.
3 - List all the volumes.
4 - Inspect each volume until I find the volumes whose (host) path match the new container volumes.

This is impractical since I need to inspect every volume. Could we have the (host) path as part of the Volume List operation? It would reduce the number of API calls a lot for this use case, which should be relatively common.

@cpuguy83

This comment has been minimized.

Show comment
Hide comment
@cpuguy83

cpuguy83 Oct 29, 2014

Contributor

@pchico83 If we try to decode the name param on inspect I think passing a path in there could work.

Contributor

cpuguy83 commented Oct 29, 2014

@pchico83 If we try to decode the name param on inspect I think passing a path in there could work.

@rhvgoyal

This comment has been minimized.

Show comment
Hide comment
@rhvgoyal

rhvgoyal Mar 12, 2015

Contributor

@cpuguy83

Only one process can manage the pool. This process knows the transaction Id and manages pool transaction Id. Two processes can't do it.

Contributor

rhvgoyal commented Mar 12, 2015

@cpuguy83

Only one process can manage the pool. This process knows the transaction Id and manages pool transaction Id. Two processes can't do it.

@dreamcat4

This comment has been minimized.

Show comment
Hide comment
@dreamcat4

dreamcat4 Mar 12, 2015

Would such improvement be able to solve the other problem: that docker is not able to bind mount volumes into the container as a different UID and GID?

dreamcat4 commented Mar 12, 2015

Would such improvement be able to solve the other problem: that docker is not able to bind mount volumes into the container as a different UID and GID?

@rhvgoyal

This comment has been minimized.

Show comment
Hide comment
@rhvgoyal

rhvgoyal Mar 12, 2015

Contributor

@cpuguy83

W.r.t complexity of dm, btrfs etc, it is already managed by graphdriver and image and container objects already use it. So we probably will not be dealing with new complexity if we extend volumes to make use of graph drivers other then VFS.

If extensions can't work on same pool where images and containers are stored, then it will not serve the use case I have been thinking of.

Also I am wondering why volume has to be a path. Why could it not be an object with a unique hash ID (like images) and then various metadata attached to it. And path will be just one of the metadata. If user specifies the path, then user is sort of responsible to making sure that volume is up before it is used by docker. Otherwise, it could be a docker managed volume and path will be automatically determined by docker (/var/lib/docker/volumes/mnt/).

Are there some patches somewhere for this extension based volume management. I want to play with it a bit and see what it will offer.

Contributor

rhvgoyal commented Mar 12, 2015

@cpuguy83

W.r.t complexity of dm, btrfs etc, it is already managed by graphdriver and image and container objects already use it. So we probably will not be dealing with new complexity if we extend volumes to make use of graph drivers other then VFS.

If extensions can't work on same pool where images and containers are stored, then it will not serve the use case I have been thinking of.

Also I am wondering why volume has to be a path. Why could it not be an object with a unique hash ID (like images) and then various metadata attached to it. And path will be just one of the metadata. If user specifies the path, then user is sort of responsible to making sure that volume is up before it is used by docker. Otherwise, it could be a docker managed volume and path will be automatically determined by docker (/var/lib/docker/volumes/mnt/).

Are there some patches somewhere for this extension based volume management. I want to play with it a bit and see what it will offer.

@yasker

This comment has been minimized.

Show comment
Hide comment
@yasker

yasker Mar 12, 2015

Contributor

@rhvgoyal @cpuguy83

The previous patch for docker volume driver I mentioned separates pool/working directory for image and volume management, since I found it caused conflict on e.g. devId allocation which is per DeviceSet in device mapper(which I allocated another DeviceSet for the volume in the patch). If we want to use the same pool, I guess there would be a little more work need to be done.

However, the major problem still is, volume is assumed to be a directory currently, rather than an object. I don't think that assumption can hold in the future. We can keep path(as source and use vfs) for backward compatibility, but ultimately I think volume should be defined as: an object can be mounted to a path of guest container. Then we can do various things to the object.

Since we're already planning to have separate volume commands for docker, it would be so natural to have the volume as an object rather than merely a path. I think it would be necessary for the new volume driver able to use graphdriver as volume driver, rather than only vfs and host mount in the future.

Contributor

yasker commented Mar 12, 2015

@rhvgoyal @cpuguy83

The previous patch for docker volume driver I mentioned separates pool/working directory for image and volume management, since I found it caused conflict on e.g. devId allocation which is per DeviceSet in device mapper(which I allocated another DeviceSet for the volume in the patch). If we want to use the same pool, I guess there would be a little more work need to be done.

However, the major problem still is, volume is assumed to be a directory currently, rather than an object. I don't think that assumption can hold in the future. We can keep path(as source and use vfs) for backward compatibility, but ultimately I think volume should be defined as: an object can be mounted to a path of guest container. Then we can do various things to the object.

Since we're already planning to have separate volume commands for docker, it would be so natural to have the volume as an object rather than merely a path. I think it would be necessary for the new volume driver able to use graphdriver as volume driver, rather than only vfs and host mount in the future.

@thaJeztah

This comment has been minimized.

Show comment
Hide comment
@thaJeztah

thaJeztah Mar 12, 2015

Member

I think volume should be defined as: an object can be mounted to a path of guest container. Then we can do various things to the object.

+1 Absolutely. IMO (and I think I mentioned that on other issues) a volume is storage where and how that storage is manager should be of no concern for the container. In a simple configuration, a volume could be stored on the host, in a directory. On a more advanced setup, this could be a remote volume or "you name it".

My ideal steps would be to (1) create/define a volume ("storage") using the desired driver. (2) connect the volume to the container.

It should be possible to manage the volume separately, for example to migrate or snapshot a volume, but all these could be dependent on the driver and (again) transparent to the container.

Member

thaJeztah commented Mar 12, 2015

I think volume should be defined as: an object can be mounted to a path of guest container. Then we can do various things to the object.

+1 Absolutely. IMO (and I think I mentioned that on other issues) a volume is storage where and how that storage is manager should be of no concern for the container. In a simple configuration, a volume could be stored on the host, in a directory. On a more advanced setup, this could be a remote volume or "you name it".

My ideal steps would be to (1) create/define a volume ("storage") using the desired driver. (2) connect the volume to the container.

It should be possible to manage the volume separately, for example to migrate or snapshot a volume, but all these could be dependent on the driver and (again) transparent to the container.

@rhvgoyal

This comment has been minimized.

Show comment
Hide comment
@rhvgoyal

rhvgoyal Mar 12, 2015

Contributor

@yasker @thaJeztah

+1 to some of your ideas.

Few thoughts.

  • I think we need a summary document which explains how this new volume architecture is going to look like. There seem to be information scattered in various threads and git trees but no single place
    explains it.
  • In new scheme of things, are we targeting one global volume driver which will drive all volumes for
    that docker intance or there can be multiple volume drivers and it will become a per volume property. That means there might be some volumes backed by in-built graph driver, other volumes backed by plugin/extension volume driver. I feel making volumedriver a per volume property is much more flexible.
  • Volume driver Plugin/extension seems to be just another way to plug in a volumedriver dynamically, but I guess core volume API will have to be defined by docker core and all plugin/extension will simply
    implement that API. I think this API should be pretty close to what graph driver is currently offering.
  • I like the idea of treating volumes as object (like images) and then maintain metadata around it to differentiate between different kind of volumes. (Instead of just treating volume like a path). A call
    into volumedriver (volume.volumeDriver.Mount()) should just make volume available at certain mount point.
  • Once should be able to use existing graphdrivers (btrfs, devicemapper etc) as volumedrivers.
  • In fact I think if we allow per volume volume drivers, then one can have two different instances of
    devicemapper graph drivers. One plugged in one which is operating on its own separate thin pool
    and another one which is in-built and operating on pool where existing images are.

Those are some of the ideas. I think if we maintain a summary document which describes new volume architecture, it will help a lot.

Contributor

rhvgoyal commented Mar 12, 2015

@yasker @thaJeztah

+1 to some of your ideas.

Few thoughts.

  • I think we need a summary document which explains how this new volume architecture is going to look like. There seem to be information scattered in various threads and git trees but no single place
    explains it.
  • In new scheme of things, are we targeting one global volume driver which will drive all volumes for
    that docker intance or there can be multiple volume drivers and it will become a per volume property. That means there might be some volumes backed by in-built graph driver, other volumes backed by plugin/extension volume driver. I feel making volumedriver a per volume property is much more flexible.
  • Volume driver Plugin/extension seems to be just another way to plug in a volumedriver dynamically, but I guess core volume API will have to be defined by docker core and all plugin/extension will simply
    implement that API. I think this API should be pretty close to what graph driver is currently offering.
  • I like the idea of treating volumes as object (like images) and then maintain metadata around it to differentiate between different kind of volumes. (Instead of just treating volume like a path). A call
    into volumedriver (volume.volumeDriver.Mount()) should just make volume available at certain mount point.
  • Once should be able to use existing graphdrivers (btrfs, devicemapper etc) as volumedrivers.
  • In fact I think if we allow per volume volume drivers, then one can have two different instances of
    devicemapper graph drivers. One plugged in one which is operating on its own separate thin pool
    and another one which is in-built and operating on pool where existing images are.

Those are some of the ideas. I think if we maintain a summary document which describes new volume architecture, it will help a lot.

@cpuguy83

This comment has been minimized.

Show comment
Hide comment
@cpuguy83

cpuguy83 Mar 12, 2015

Contributor

Since this isn't really mergable today, it doesn't really make sense to keep it open, so I'm going to go ahead and close.

So a lot of this discussion is really great, but is probably better suited for docker-dev ML at this point, so it would be really great to continue there, or even on IRC for specific questions.

Thanks.

Contributor

cpuguy83 commented Mar 12, 2015

Since this isn't really mergable today, it doesn't really make sense to keep it open, so I'm going to go ahead and close.

So a lot of this discussion is really great, but is probably better suited for docker-dev ML at this point, so it would be really great to continue there, or even on IRC for specific questions.

Thanks.

@KodyKantor

This comment has been minimized.

Show comment
Hide comment
@KodyKantor

KodyKantor Mar 31, 2015

I like this.
Are there any plans to merge the above functionality? Is there any other active discussion somewhere on docker volume proposals?

KodyKantor commented Mar 31, 2015

I like this.
Are there any plans to merge the above functionality? Is there any other active discussion somewhere on docker volume proposals?

@cpuguy83

This comment has been minimized.

Show comment
Hide comment
@cpuguy83

cpuguy83 Apr 2, 2015

Contributor

@KodyKantor Some other bits of the code-base need to be handled first so this can be implemented with the suggested API.

Contributor

cpuguy83 commented Apr 2, 2015

@KodyKantor Some other bits of the code-base need to be handled first so this can be implemented with the suggested API.

julienvantyghem pushed a commit to julienvantyghem/dockwrap that referenced this pull request Apr 27, 2015

Julien Vantyghem
Systematically remove volumes with containers, to avoid dangling volu…
…mes.

To clean up existing dangling volumes (more or less) safely, use https://github.com/chadoe/docker-cleanup-volumes.git, at least until moby/moby#8484 is tackled.

@icecrime icecrime referenced this pull request Jun 26, 2015

Closed

Top-level volume management #14214

0 of 2 tasks complete
@laktak

This comment has been minimized.

Show comment
Hide comment
@laktak

laktak Aug 5, 2015

@cpuguy83 This issue is referenced from https://docs.docker.com/userguide/dockervolumes/:

Note: Docker will not warn you when removing a container without providing the -v option to delete its volumes. If you remove containers without using the -v option, you may end up with “dangling” volumes; volumes that are no longer referenced by a container. Dangling volumes are difficult to get rid of and can take up a large amount of disk space. We’re working on improving volume management and you can check progress on this in pull request #8484

Since this is closed, where can I go to check the progress on improving volume management?

laktak commented Aug 5, 2015

@cpuguy83 This issue is referenced from https://docs.docker.com/userguide/dockervolumes/:

Note: Docker will not warn you when removing a container without providing the -v option to delete its volumes. If you remove containers without using the -v option, you may end up with “dangling” volumes; volumes that are no longer referenced by a container. Dangling volumes are difficult to get rid of and can take up a large amount of disk space. We’re working on improving volume management and you can check progress on this in pull request #8484

Since this is closed, where can I go to check the progress on improving volume management?

@thaJeztah

This comment has been minimized.

Show comment
Hide comment
@thaJeztah

thaJeztah Aug 5, 2015

Member

@laktak thanks for reporting; #14214 is a "tracking" issue for issues related to volume management. Are you perhaps interested in creating a pull-request to update the link in the documentation? The Markdown file that is used to generate that page in the documentation can be found here /docs/userguide/dockervolumes.md

Member

thaJeztah commented Aug 5, 2015

@laktak thanks for reporting; #14214 is a "tracking" issue for issues related to volume management. Are you perhaps interested in creating a pull-request to update the link in the documentation? The Markdown file that is used to generate that page in the documentation can be found here /docs/userguide/dockervolumes.md

@laktak

This comment has been minimized.

Show comment
Hide comment
@laktak

laktak Aug 7, 2015

The Markdown file that is used to generate that page in the documentation can be found here /docs/userguide/dockervolumes.md

@thaJeztah The text has already been updated (not by me), it's just not live.

laktak commented Aug 7, 2015

The Markdown file that is used to generate that page in the documentation can be found here /docs/userguide/dockervolumes.md

@thaJeztah The text has already been updated (not by me), it's just not live.

@ovidiub13

This comment has been minimized.

Show comment
Hide comment
@ovidiub13

ovidiub13 Aug 12, 2015

I'm lost, was this functionality implemented or not?

ovidiub13 commented Aug 12, 2015

I'm lost, was this functionality implemented or not?

@thaJeztah

This comment has been minimized.

Show comment
Hide comment
@thaJeztah

thaJeztah Aug 12, 2015

Member

@ovidiub13 no, it's not implemented (yet); see #14214

Member

thaJeztah commented Aug 12, 2015

@ovidiub13 no, it's not implemented (yet); see #14214

@yasker

This comment has been minimized.

Show comment
Hide comment
@yasker

yasker Aug 12, 2015

Contributor

@thaJeztah @ovidiub13 In fact the volume management has already been implemented by @cpuguy83 at #14242 . It's in review now and I suppose it would be merged in v1.9.

Contributor

yasker commented Aug 12, 2015

@thaJeztah @ovidiub13 In fact the volume management has already been implemented by @cpuguy83 at #14242 . It's in review now and I suppose it would be merged in v1.9.

@thaJeztah

This comment has been minimized.

Show comment
Hide comment
@thaJeztah

thaJeztah Aug 12, 2015

Member

@yasker yes, you're right; I intended to say "it's not merged yet"

Member

thaJeztah commented Aug 12, 2015

@yasker yes, you're right; I intended to say "it's not merged yet"

@ovidiub13

This comment has been minimized.

Show comment
Hide comment
@ovidiub13

ovidiub13 Aug 13, 2015

Thank you. I'm looking forward to that release.

ovidiub13 commented Aug 13, 2015

Thank you. I'm looking forward to that release.

@thaJeztah

This comment has been minimized.

Show comment
Hide comment
@thaJeztah

thaJeztah Aug 26, 2015

Member

For those following this; this functionally is now implemented in #14242, which was just merged, and will be in docker 1.9

If you want to test it before that, nightly builds, build from master can be found at https://master.dockerproject.org

Member

thaJeztah commented Aug 26, 2015

For those following this; this functionally is now implemented in #14242, which was just merged, and will be in docker 1.9

If you want to test it before that, nightly builds, build from master can be found at https://master.dockerproject.org

@cpuguy83 cpuguy83 deleted the cpuguy83:add_volumes_command branch Sep 20, 2017

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