ping @erikh @lukemarsden @clintonskitson @jvinod @srust @ibuildthecloud

@cpuguy83 nice! This will be great. Thanks for the ping.

I was thinking of the name of the field. I know, this is always the most difficult part ;) The types of information included in this field could be wide and varying. Config, run-time state, volume options, status of the volume, other driver specific information, etc. An alternative would be to just call it Metadata.

That said, I think either one could work, there's probably not a perfect answer. Would be curious what others thought.

Yeah, I wanted to avoid Metadata -- but also not tied to Status.

How about details? Any reason reason for this not being map[string]string?

Okay..

One more suggestion: Detail or Details.

This would follow from the description of "low-level details of the volume". Perhaps this could someday allow inspect to conditionally show these extended "details".

Example:

[
    {
        "Name": "test-vol",
        "Driver": "driver",
        "Mountpoint": "/mnt/test-vol"
        "Details": {
            "CreatedAt": "2016-03-07T21:15:24.27864192Z"
            "Status":    "online",
            "User":      "cpuguy83",
            "Mode":      "readwrite",
        },
    }
]

[][]string allows you to, for instance, provide a list instead of a simple "string"="string"

[
    [ "foo", "bar", "baz", "qux"],
    ["hello", "world"]
]

This can really come in handy especially when presenting something other than straight json to the user.

Cool!

+1 for Details and map[string]string

On 7 Mar 2016, at 14:30, Clinton Kitson wrote:

How about details? Any reason reason for this not being
map[string]string?

---

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

Some weirdness on the CI.

Design LGTM.

@cpuguy83 I do like the example that @srust gave above re how Details would show up if it was map[string]string. It seems like the [][]string would be a pretty unstructured view when it comes out of the CLI. Any ideas for how that would get laid out?

Hi @cpuguy83,

Please tell me if this is beyond the scope of this PR, but I think it would be pretty awesome if there were two separate objects returned here. One for the user-supplied 'Opts', and one for the driver 'Details'. This would give the user a clear view as to how the volume was configured. And the driver could put any of its own driver-specific details in the 'Details'.

A user supplied value in the volume 'Opts' could impact the volume in many ways (ie: an option is not necessarily a 1-1 mapping to something in Detail. It could turn on many different capabilities / fields).

And both 'Opts' and 'Details' would be optional, for a driver to return.

Example:
docker volume inspect $(docker volume create --opt type=awesome)

[
    {
        "Name": "test-vol",
        "Driver": "driver",
        "Mountpoint": "/mnt/test-vol",
        "Opts": {
            "type": "awesome",
        },
        "Details": {
            "CreatedAt": "2016-03-07T21:15:24.27864192Z"
            "Status":    "online",
            "User":      "cpuguy83",
            "Mode":      "readwrite",
            "Speed":     "fast",
        },
    }
]

I'm also on board with map[string]string. I think it is important to be able to show fields such as "Status": "online" in the details, as a clear key/value. Unless I'm missing something with how [][]string would work?

Thanks.

@srust we'll have a separate API for getting driver related info... Likely something like "docker plugin inspect "

@cpuguy83 oh, cool! In the context of this PR, I'm still referring to the volume info..

@srust We can keep this in one field for now and always expand later if it's really needed.

In terms of presentation, we can handle this at the client level, it's not a big deal.
I'll change this to [][2]string, though, which makes the output a bit more predictable.

@cpuguy83 FWIW libnetwork provides a DriverInfo() (map[string]interface{}, error) where the key is well-known label and value-type is derived out of it. This gives more control and portable way for docker daemon to depend on the data returned by a particular driver. But this can very well be a [string]string.

@mavenugo Is this for info on networks or for network drivers?
I don't plan to use any of this information in engine... but map[string]interface{} does work as well.

LGTM

How are you planning on formatting the struct in the CLI? Can we give some examples of what this would look like as CLI transcripts showing how we could render [][]string, map[string][string], or just string and how they might look? I am slightly leaning towards map[string][string] because it's more structured, but would be curious to see how you imagine this being rendered in docker volume ls.

Or is that not the use case for this? In which case what is?

@lukemarsden I would not display this info on volume ls only on inspect.

btw, I updated the engine-api PR to use a map[string]interface

@cpuguy83 perhaps we should add a change-log to docs/extend/plugins_volume.md as well (like we have for the remote API). It may make it easier for plugin-developers to see what changed between versions?

Updated, added changelog to volume plugin doc.

docs LGTM, thanks!

LGTM 🐮

@cpuguy83, request to reach out to myself or @wallrj or @myechuri for future items that would relate to clusterhq/flocker volumes. cheers!