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

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

@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"?

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

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

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

Perfect, thanks for the explanation!

Removed [WIP]
This is ready.

@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.

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

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)

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.

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

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

What about volume export/import ?

@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.

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

@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.

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

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?

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