Support docker volume API

[jvinod]

Docker 1.9 will have a new volumes API - add openstorage support for moby/moby#14242

[kunalkushwaha]

I am currently working on this issue.

Findings:

Docker volume APIs identify volumes with their Name.
Name of volume either system generated uuid or user can specify the name in argument.

$ docker volume  create -d vfs --name=vol1
vol1

$ docker volume  create -d vfs
fd2913a52b3e2d7f8de0d83e8e53142d4bc8c093cd0c9c33033ffa1f60116e0d

$ docker volume  ls
DRIVER              VOLUME NAME
local               8b26f006dc081110eeb8aee577289c25b58d8db7d780eb42a5209d36e4d42976
vfs                 vol1
vfs                 fd2913a52b3e2d7f8de0d83e8e53142d4bc8c093cd0c9c33033ffa1f60116e0d

In OSD, uuid generated by OSD is key to identify the volumes.
So to integrate with Volume APIs, mapping with osd uuid and Name is required, and Path API of docker, should lookup with Volume Name instead of current osd's uuid.

• Also, driver specific parameters can be passed as --opts, so nothing is required there.
  I feel one more Method in Docker Volume API is required to print help of driver parameters.

[jvinod]

What stops us from creating a volume with the same name as passed in from the volumes API? I.e the VolumeID == Volume name from from the volumes API

[kunalkushwaha]

Creation is successful, but path of volume cannot be found, as Docker invokes path() method with "Name" not uuid.

NOTE: Also, we need to keep track with moby/moby#15997 & moby/moby#16534

[jvinod]

Understood. I am suggesting we don't create the UUID if the name is provided. I.e the volumeID is the name that is provided. If it is not provided, we generate a UUID.

So in your examples:

$ docker volume  create -d osd --name=vol1
vol1
#VolumeID == vol1

$ docker volume  create -d osd
cfbb378d-1e0b-4321-8946-63cbb76ccd4d
#VolumeID == cfbb378d-1e0b-4321-8946-63cbb76ccd4d

$ docker volume  ls
DRIVER              VOLUME NAME
osd                 vol1
osd                 cfbb378d-1e0b-4321-8946-63cbb76ccd4d

[kunalkushwaha]

I am really not sure for this.

Can there be such case

• Move the volume to other node , Not clean node & joins the cluster later.
• Name may conflict here
• uuid will ensure its uniqueness, where as name will ensure compatibility with docker

thoughts ?

[jvinod]

The name needs to be unique in a driver's namespace across the entire cluster. If it is not, then even the mapping function, that you propose, will not work.

[kunalkushwaha]

Yes, that is true, I was thinking in case of conflict, how to resolve.

Conflict cases can be:

1. Split brain in network. ( volumes created during this phase)
2. If it will be allowed to join a node (with volumes) in cluster.

UUID will be unique, so resolution within cluster is just to resolve the names.
In case of only names, after conflict resolution, a complete new identity need to be give to volume.

[kunalkushwaha]

@jvinod How to proceed on this?

[jvinod]

Let's implement the REST interface for the volume API and translate that to VolumeDriver interface. Defer the lookup/inspect by VolumeName to the volume driver implementation.
@peter-edge has some thoughts on implementing the REST interface using protobufs

[kunalkushwaha]

Actually, nothing much is required for REST Interface. Only in existing create and remove REST interfaces, volume create and remove code needs to be added.

I tested code with vfs driver, by passing name instead of volumeid, to bypass lookup issue, everything works fine.

Yes, We need to think on changes, how volume should be treated within osd.

diff --git a/api/server/docker.go b/api/server/docker.go
index e78dc81..4555ad9 100644
--- a/api/server/docker.go
+++ b/api/server/docker.go
@@ -135,8 +135,25 @@ func (d *driver) create(w http.ResponseWriter, r *http.Request) {
        // It is an error if the volume doesn't already exist.
        _, err = d.volFromName(request.Name)
        if err != nil {
-               e := d.volNotFound(method, request.Name, err, w)
-               json.NewEncoder(w).Encode(&volumeResponse{Err: e})
+
+               //If Volume not found, Create volume.
+
+               v, err := volume.Get(d.name)
+               if err != nil {
+                       d.logReq(method, request.Name).Debugf("Unable to get volume driver")
+                       return
+               }
+
+               //Build the Locator, Source and Spec
+               volLocator := types.VolumeLocator{Name: request.Name}
+               //FIXME(Kunal): Extract other parameters from request.
+               volOptions := types.Source{}
+               volSpecs := types.VolumeSpec{}
+
+               ID, err := v.Create(volLocator, &volOptions, &volSpecs)
+               fmt.Println(ID, err)
+
+               json.NewEncoder(w).Encode(&volumeResponse{})
                return
        }

@@ -161,6 +178,17 @@ func (d *driver) remove(w http.ResponseWriter, r *http.Request) {
                return
        }

+       v, err := volume.Get(d.name)
+       if err != nil {
+               d.logReq(method, request.Name).Debugf("Unable to get volume driver")
+               return
+       }
+       err = v.Delete(types.VolumeID(request.Name))
+       if err != nil {
+
+               d.logReq(method, request.Name).Errorf("Error in volume deletion %v", err)
+       }
+
        json.NewEncoder(w).Encode(&volumeResponse{})
 }

[bufdev]

I'm going to attempt to make a pass at the generated protobuf API in a day or two, an example of what this will look like would be https://github.com/peter-edge/go-dockervolume/blob/master/dockervolume.proto

I'm working on the tool right now that makes it easy to compile protobufs like this, it's not great right now :)

[kunalkushwaha]

This sounds great :), So this will be for REST interfaces for Volume API from Docker to OSD right. It wont affect the driver side.

I mean instead of JSON, protobuf package will be used for communication. right?

[bufdev]

Either/or, github.com/gengo/grpc-gateway is a good read

On Wednesday, October 14, 2015, Kunal Kushwaha notifications@github.com
wrote:

This sounds great :), So this will be for REST interfaces for Volume API
from Docker to OSD right. It wont affect the driver side.

I mean instead of JSON, protobuf package will be used for communication.
right?

—
Reply to this email directly or view it on GitHub
#7 (comment)
.