Add volume api

[cpuguy83]

Posting this up here for discussion.

TODO:

• Add CLI docs
• Add CLI tests
• Accounting for the local volume driver is not good enough and allows for things like calling docker volume rm on a volume multiple times to remove.

[kojiromike]

sp COMMAND

[yasker]

And is it possible to omit the driver option when rm/inspect? Docker should know which volume used which driver when created?

[cpuguy83]

@yasker No, not really.
Volumes are not managed by docker at all, and there is no guarantee of uniqueness of the name between drivers.

[yasker]

@cpuguy83 I see, thanks.

Just curious, would we have ability to create docker disposable volume through docker volume command? Like what I shown above, without "-d"?

[cpuguy83]

Without "-d" would just use the default driver, which is currently hard coded to the "local" driver.

[jonasrosland]

I see we have this and #13924, how much of the work from that one could be reused here?

[cpuguy83]

@jonasrosland They are completely different things.
#13924 is refactoring the internal implementation, this is adding a public/remote API/CLI to these drivers.

[jonasrosland]

Perfect, thanks for the explanation!

[cpuguy83]

Removed [WIP]
This is ready.

[yasker]

@cpuguy83 It's strange, seems github got a glitch. I once commented on old commit that the specifying of driver/name should be consistent across the commands. Now I cannot find it anywhere...

In short, the create/rm/inspect should use same order/parameter for input driver and volume name. Now inspect/rm using [DRIVER] [NAME], but create use "--name [NAME] --driver [DRIVER]"

I think they should all be: "--name [NAME]" with "--driver [DRIVER]" as optional. If DRIVER is first augment, it cannot be omitted.

Something like this would be useful:

docker volume create vol1
docker volume create vol1 -d volume_driver_1
docker volume rm vol1
docker volume rm vol1 -d volume_driver_1
docker volume inspect vol1
docker volume inspect vol1 -d volume_driver_1

And without driver it would default to "local" as we discussed.

I omitted the "--name" above because it's pretty required, but not the driver option.

[calavera]

I agree with @yasker. The name should always be the first argument for every command and the driver should always be a flag.

[cpuguy83]

I agree as it is right here is not good (and really horrible to actually use as I've learned the last couple of days!).
However I don't think driver as a flag for inspect/rm is good as you may end up hitting the wrong volume in this case.
It also makes piping commands together extremely difficult.

What I have now, just making some test/doc tweaks, is expecting a volume to be specified as <driver>/<name>.
Then with docker volume ls -q, it outputs <driver>/<name>\n... since a name by itself is useless.
This allows you to combine commands together similar to with docker ps, like docker volume inspect $(docker volume ls -q)

[coding2012]

I have a use-case to DISABLE VOLUME tags inside Dockerfiles. For example let's say I'm automating the build and deployment of dev and feature branches and possibly QA. For these environments I want to be able to build a pre-existing postgres image that has my schema and testing data saved, and pushed to a public repository. When such pre-existing database images have VOLUME dockerfile instructions, I pretty much have to either copy and paste the dockerfile without the VOLUME directive OR create a data-only container, tag/commit and push (haven't tested this route). Both of these are not desireable for staging data solutions that you want to push to a docker repo.

[kojiromike]

yes, this ^^ @coding2012; however, isn't it a separate issue?

[thaJeztah]

@coding2012 @kojiromike that's indeed not really related to this PR. See #8177 (and #3465) for a prior discussion on that.

[omribahumi]

What about volume export/import ?

[cpuguy83]

@omribahuni this is not implemented in docker and should be a concern of the volume driver itself.
You can also fire up a container with the volume and tar/gzip it for a naive backup.

[omribahumi]

@cpuguy83 I was expecting docker to do that exactly, like docker save.

[cpuguy83]

@omribahumi For persistent data, the storage backend probably already has a solution for backing up data, probably much more efficiently than docker could, and if not running a container and manually backing up with tar/gzip is a simple/elegant solution.

[thaJeztah]

@cpuguy83 may be something we should document; i.e. using the plugin's tools, or how to do an export

[trkoch]

Thanks for implementing this! Makes handling volumes a whole lot easier.

After reading through docs (and skimming comments here) I'm still unsure about the approach taken to seed data of named volumes. When creating containers with auto-created (anonymous) volumes, mounting a volume to an existing folder results in existing data to be copied from the image to the volume. This does not apply to host mounted volumes. What about named volumes?

[trkoch]

It appears named volumes are treated just like host mounted volumes.

Anonymous volumes

$ docker run --rm -it -v /etc debian ls -1 /etc | wc -l | awk '{print $1}'
92

Host mounted volumes

$ docker run --rm -it -v $(pwd)/etc:/etc debian ls -1 /etc | wc -l | awk '{print $1}'
3

Named volumes

$ docker run --rm -it -v test:/etc debian ls -1 /etc | wc -l | awk '{print $1}'
3