Hello all, and thanks for the feedbacks! Let me try to answer some of the questions here.

API was deliberately kept minimal in this first version. We'd rather first hear from the community what use cases they can't achieve with the current design, and "poke more holes" as necessary. On your specific example of passing the container ID, I'd like to hear an example where it's required (right now we provide a unique volume name which I believe is sufficient).
Driver-specific are indeed very likely to be needed at some point, they just weren't implemented so far.
We might have more plugin types in the future. One of the reasons we marked the feature as "experimental" is that we still don't really know what's going to be the community and user adoption. As we gain more feedback and use cases, we'll refine the UX and potentially expand the scope. API plugins is definitely something that we are thinking about (think Powerstrip), but our current API implementation might need a good rewrite before that.

You're right that the --volume-driver syntax is not ideal. There are several reasons behind it right now:

The goal is clearly to have a top-level docker volume command to manage volumes, which will open the possibility for per-volume drivers¹ (e.g., docker volume create foo --driver=bar). This is by the way exactly the plan for network management too. We didn't want to put this as a requirement for this first release of the feature, which is why we went for the simplest. Brian I know you had work on this in the past, I think we're ready to do this for 1.8.0 if you interested.
Solomon was very clear that he doesn't want the driver name to appear as part of the volume specification. His reasoning for this is that we want to decouple volume definition from the operational aspect (e.g., "my container needs a volume X" versus "volume X should be managed by driver Y"). He'd ideally want it to be possible to label volumes and somehow leave it to a separate (ops defined) configuration to associates labels to drivers.

I hope this clears up some of the questions.

¹ Truth is there already is a hackish way to do multiple volume drivers for a single containers using --volume-from, but that's far from convenient.

Experimental feedback - Volume plugins #13420

Description

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions