Initial commit

vendor/github.com/hyperhq/hypercli/docs/extend/authorization.md

@@ -0,0 +1,253 @@
+<!--[metadata]>
++++
+title = "Access authorization plugin"
+description = "How to create authorization plugins to manage access control to your Docker daemon."
+keywords = ["security, authorization, authentication, docker, documentation, plugin, extend"]
+[menu.main]
+parent = "engine_extend"
+weight = -1
++++
+<![end-metadata]-->
+
+
+# Create an authorization plugin
+
+Docker's out-of-the-box authorization model is all or nothing. Any user with
+permission to access the Docker daemon can run any Docker client command. The
+same is true for callers using Docker's remote API to contact the daemon. If you
+require greater access control, you can create authorization plugins and add
+them to your Docker daemon configuration. Using an authorization plugin, a
+Docker administrator can configure granular access policies for managing access
+to Docker daemon.
+
+Anyone with the appropriate skills can develop an authorization plugin. These
+skills, at their most basic, are knowledge of Docker, understanding of REST, and
+sound programming knowledge. This document describes the architecture, state,
+and methods information available to an authorization plugin developer.
+
+## Basic principles
+
+Docker's [plugin infrastructure](plugin_api.md) enables
+extending Docker by loading, removing and communicating with
+third-party components using a generic API. The access authorization subsystem
+was built using this mechanism.
+
+Using this subsystem, you don't need to rebuild the Docker daemon to add an
+authorization plugin.  You can add a plugin to an installed Docker daemon. You do
+need to restart the Docker daemon to add a new plugin.
+
+An authorization plugin approves or denies requests to the Docker daemon based
+on both the current authentication context and the command context. The
+authentication context contains all user details and the authentication method.
+The command context contains all the relevant request data.
+
+Authorization plugins must follow the rules described in [Docker Plugin API](plugin_api.md).
+Each plugin must reside within directories described under the
+[Plugin discovery](plugin_api.md#plugin-discovery) section.
+
+**Note**: the abbreviations `AuthZ` and `AuthN` mean authorization and authentication
+respectively.
+
+## Basic architecture
+
+You are responsible for registering your plugin as part of the Docker daemon
+startup. You can install multiple plugins and chain them together. This chain
+can be ordered. Each request to the daemon passes in order through the chain.
+Only when all the plugins grant access to the resource, is the access granted.
+
+When an HTTP request is made to the Docker daemon through the CLI or via the
+remote API, the authentication subsystem passes the request to the installed
+authentication plugin(s). The request contains the user (caller) and command
+context. The plugin is responsible for deciding whether to allow or deny the
+request.
+
+The sequence diagrams below depict an allow and deny authorization flow:
+
+![Authorization Allow flow](images/authz_allow.png)
+
+![Authorization Deny flow](images/authz_deny.png)
+
+Each request sent to the plugin includes the authenticated user, the HTTP
+headers, and the request/response body. Only the user name and the
+authentication method used are passed to the plugin. Most importantly, no user
+credentials or tokens are passed. Finally, not all request/response bodies
+are sent to the authorization plugin. Only those request/response bodies where
+the `Content-Type` is either `text/*` or `application/json` are sent.
+
+For commands that can potentially hijack the HTTP connection (`HTTP
+Upgrade`), such as `exec`, the authorization plugin is only called for the
+initial HTTP requests. Once the plugin approves the command, authorization is
+not applied to the rest of the flow. Specifically, the streaming data is not
+passed to the authorization plugins. For commands that return chunked HTTP
+response, such as `logs` and `events`, only the HTTP request is sent to the
+authorization plugins.
+
+During request/response processing, some authorization flows might
+need to do additional queries to the Docker daemon. To complete such flows,
+plugins can call the daemon API similar to a regular user. To enable these
+additional queries, the plugin must provide the means for an administrator to
+configure proper authentication and security policies.
+
+## Docker client flows
+
+To enable and configure the authorization plugin, the plugin developer must
+support the Docker client interactions detailed in this section.
+
+### Setting up Docker daemon
+
+Enable the authorization plugin with a dedicated command line flag in the
+`--authorization-plugin=PLUGIN_ID` format. The flag supplies a `PLUGIN_ID`
+value. This value can be the plugin’s socket or a path to a specification file.
+
+```bash
+$ docker daemon --authorization-plugin=plugin1 --authorization-plugin=plugin2,...
+```
+
+Docker's authorization subsystem supports multiple `--authorization-plugin` parameters.
+
+### Calling authorized command (allow)
+
+```bash
+$ docker pull centos
+...
+f1b10cd84249: Pull complete
+...
+```
+
+### Calling unauthorized command (deny)
+
+```bash
+$ docker pull centos
+...
+docker: Error response from daemon: authorization denied by plugin PLUGIN_NAME: volumes are not allowed.
+```
+
+### Error from plugins
+
+```bash
+$ docker pull centos
+...
+docker: Error response from daemon: plugin PLUGIN_NAME failed with error: AuthZPlugin.AuthZReq: Cannot connect to the Docker daemon. Is the docker daemon running on this host?.
+```
+
+## API schema and implementation
+
+In addition to Docker's standard plugin registration method, each plugin
+should implement the following two methods:
+
+* `/AuthzPlugin.AuthZReq` This authorize request method is called before the Docker daemon processes the client request.
+
+* `/AuthzPlugin.AuthZRes` This authorize response method is called before the response is returned from Docker daemon to the client.
+
+#### /AuthzPlugin.AuthZReq
+
+**Request**:
+
+```json
+{
+    "User":              "The user identification",
+    "UserAuthNMethod":   "The authentication method used",
+    "RequestMethod":     "The HTTP method",
+    "RequestUri":        "The HTTP request URI",
+    "RequestBody":       "Byte array containing the raw HTTP request body",
+    "RequestHeader":     "Byte array containing the raw HTTP request header as a map[string][]string ",
+    "RequestStatusCode": "Request status code"
+}
+```
+
+**Response**:
+
+```json
+{
+    "Allow": "Determined whether the user is allowed or not",
+    "Msg":   "The authorization message",
+    "Err":   "The error message if things go wrong"
+}
+```
+#### /AuthzPlugin.AuthZRes
+
+**Request**:
+
+```json
+{
+    "User":              "The user identification",
+    "UserAuthNMethod":   "The authentication method used",
+    "RequestMethod":     "The HTTP method",
+    "RequestUri":        "The HTTP request URI",
+    "RequestBody":       "Byte array containing the raw HTTP request body",
+    "RequestHeader":     "Byte array containing the raw HTTP request header as a map[string][]string",
+    "RequestStatusCode": "Request status code",
+    "ResponseBody":      "Byte array containing the raw HTTP response body",
+    "ResponseHeader":    "Byte array containing the raw HTTP response header as a map[string][]string",
+    "ResponseStatusCode":"Response status code"
+}
+```
+
+**Response**:
+
+```json
+{
+   "Allow":              "Determined whether the user is allowed or not",
+   "Msg":                "The authorization message",
+   "Err":                "The error message if things go wrong",
+   "ModifiedBody":       "Byte array containing a modified body of the raw HTTP body (or nil if no changes required)",
+   "ModifiedHeader":     "Byte array containing a modified header of the HTTP response (or nil if no changes required)",
+   "ModifiedStatusCode": "int containing the modified version of the status code (or 0 if not change is required)"
+}
+```
+
+The modified response enables the authorization plugin to manipulate the content
+of the HTTP response. In case of more than one plugin, each subsequent plugin
+receives a response (optionally) modified by a previous plugin.
+
+### Request authorization
+
+Each plugin must support two request authorization messages formats, one from the daemon to the plugin and then from the plugin to the daemon. The tables below detail the content expected in each message.
+
+#### Daemon -> Plugin
+
+Name                   | Type              | Description
+-----------------------|-------------------|-------------------------------------------------------
+User                   | string            | The user identification
+Authentication method  | string            | The authentication method used
+Request method         | enum              | The HTTP method (GET/DELETE/POST)
+Request URI            | string            | The HTTP request URI including API version (e.g., v.1.17/containers/json)
+Request headers        | map[string]string | Request headers as key value pairs (without the authorization header)
+Request body           | []byte            | Raw request body
+
+
+#### Plugin -> Daemon
+
+Name    | Type   | Description
+--------|--------|----------------------------------------------------------------------------------
+Allow   | bool   | Boolean value indicating whether the request is allowed or denied
+Msg     | string | Authorization message (will be returned to the client in case the access is denied)
+Err     | string | Error message (will be returned to the client in case the plugin encounter an error. The string value supplied may appear in logs, so should not include confidential information)
+
+### Response authorization
+
+The plugin must support two authorization messages formats, one from the daemon to the plugin and then from the plugin to the daemon. The tables below detail the content expected in each message.
+
+#### Daemon -> Plugin
+
+
+Name                    | Type              | Description
+----------------------- |------------------ |----------------------------------------------------
+User                    | string            | The user identification
+Authentication method   | string            | The authentication method used
+Request method          | string            | The HTTP method (GET/DELETE/POST)
+Request URI             | string            | The HTTP request URI including API version (e.g., v.1.17/containers/json)
+Request headers         | map[string]string | Request headers as key value pairs (without the authorization header)
+Request body            | []byte            | Raw request body
+Response status code    | int               | Status code from the docker daemon
+Response headers        | map[string]string | Response headers as key value pairs
+Response body           | []byte            | Raw docker daemon response body
+
+
+#### Plugin -> Daemon
+
+Name    | Type   | Description
+--------|--------|----------------------------------------------------------------------------------
+Allow   | bool   | Boolean value indicating whether the response is allowed or denied
+Msg     | string | Authorization message (will be returned to the client in case the access is denied)
+Err     | string | Error message (will be returned to the client in case the plugin encounter an error. The string value supplied may appear in logs, so should not include confidential information)

vendor/github.com/hyperhq/hypercli/docs/extend/index.md

@@ -0,0 +1,22 @@
+<!--[metadata]>
++++
+title = "Extend Engine"
+description = "How to extend Docker Engine with plugins"
+keywords = ["extend, plugins, docker, documentation, developer"]
+[menu.main]
+identifier = "engine_extend"
+parent = "engine_use"
+weight = 6
++++
+<![end-metadata]-->
+
+
+## Extending Docker Engine
+
+Currently, you can extend Docker Engine by adding a plugin. This section contains the following topics:
+
+* [Understand Docker plugins](plugins.md)
+* [Write a volume plugin](plugins_volume.md)
+* [Write a network plugin](plugins_network.md)
+* [Write an authorization plugin](authorization.md)
+* [Docker plugin API](plugin_api.md)

vendor/github.com/hyperhq/hypercli/docs/extend/plugin_api.md

@@ -0,0 +1,135 @@
+<!--[metadata]>
++++
+title = "Plugins API"
+description = "How to write Docker plugins extensions "
+keywords = ["API, Usage, plugins, documentation, developer"]
+[menu.main]
+parent = "engine_extend"
+weight=1
++++
+<![end-metadata]-->
+
+# Docker Plugin API
+
+Docker plugins are out-of-process extensions which add capabilities to the
+Docker Engine.
+
+This page is intended for people who want to develop their own Docker plugin.
+If you just want to learn about or use Docker plugins, look
+[here](plugins.md).
+
+## What plugins are
+
+A plugin is a process running on the same docker host as the docker daemon,
+which registers itself by placing a file in one of the plugin directories described in [Plugin discovery](#plugin-discovery).
+
+Plugins have human-readable names, which are short, lowercase strings. For
+example, `flocker` or `weave`.
+
+Plugins can run inside or outside containers. Currently running them outside
+containers is recommended.
+
+## Plugin discovery
+
+Docker discovers plugins by looking for them in the plugin directory whenever a
+user or container tries to use one by name.
+
+There are three types of files which can be put in the plugin directory.
+
+* `.sock` files are UNIX domain sockets.
+* `.spec` files are text files containing a URL, such as `unix:///other.sock`.
+* `.json` files are text files containing a full json specification for the plugin.
+
+UNIX domain socket files must be located under `/run/docker/plugins`, whereas
+spec files can be located either under `/etc/docker/plugins` or `/usr/lib/docker/plugins`.
+
+The name of the file (excluding the extension) determines the plugin name.
+
+For example, the `flocker` plugin might create a UNIX socket at
+`/run/docker/plugins/flocker.sock`.
+
+You can define each plugin into a separated subdirectory if you want to isolate definitions from each other.
+For example, you can create the `flocker` socket under `/run/docker/plugins/flocker/flocker.sock` and only
+mount `/run/docker/plugins/flocker` inside the `flocker` container.
+
+Docker always searches for unix sockets in `/run/docker/plugins` first. It checks for spec or json files under
+`/etc/docker/plugins` and `/usr/lib/docker/plugins` if the socket doesn't exist. The directory scan stops as
+soon as it finds the first plugin definition with the given name.
+
+### JSON specification
+
+This is the JSON format for a plugin:
+
+```json
+{
+  "Name": "plugin-example",
+  "Addr": "https://example.com/docker/plugin",
+  "TLSConfig": {
+    "InsecureSkipVerify": false,
+    "CAFile": "/usr/shared/docker/certs/example-ca.pem",
+    "CertFile": "/usr/shared/docker/certs/example-cert.pem",
+    "KeyFile": "/usr/shared/docker/certs/example-key.pem",
+  }
+}
+```
+
+The `TLSConfig` field is optional and TLS will only be verified if this configuration is present.
+
+## Plugin lifecycle
+
+Plugins should be started before Docker, and stopped after Docker.  For
+example, when packaging a plugin for a platform which supports `systemd`, you
+might use [`systemd` dependencies](
+http://www.freedesktop.org/software/systemd/man/systemd.unit.html#Before=) to
+manage startup and shutdown order.
+
+When upgrading a plugin, you should first stop the Docker daemon, upgrade the
+plugin, then start Docker again.
+
+## Plugin activation
+
+When a plugin is first referred to -- either by a user referring to it by name
+(e.g.  `docker run --volume-driver=foo`) or a container already configured to
+use a plugin being started -- Docker looks for the named plugin in the plugin
+directory and activates it with a handshake. See Handshake API below.
+
+Plugins are *not* activated automatically at Docker daemon startup. Rather,
+they are activated only lazily, or on-demand, when they are needed.
+
+## API design
+
+The Plugin API is RPC-style JSON over HTTP, much like webhooks.
+
+Requests flow *from* the Docker daemon *to* the plugin.  So the plugin needs to
+implement an HTTP server and bind this to the UNIX socket mentioned in the
+"plugin discovery" section.
+
+All requests are HTTP `POST` requests.
+
+The API is versioned via an Accept header, which currently is always set to
+`application/vnd.docker.plugins.v1+json`.
+
+## Handshake API
+
+Plugins are activated via the following "handshake" API call.
+
+### /Plugin.Activate
+
+**Request:** empty body
+
+**Response:**
+```
+{
+    "Implements": ["VolumeDriver"]
+}
+```
+
+Responds with a list of Docker subsystems which this plugin implements.
+After activation, the plugin will then be sent events from this subsystem.
+
+## Plugin retries
+
+Attempts to call a method on a plugin are retried with an exponential backoff
+for up to 30 seconds. This may help when packaging plugins as containers, since
+it gives plugin containers a chance to start up before failing any user
+containers which depend on them.

vendor/github.com/hyperhq/hypercli/docs/extend/plugins.md

@@ -0,0 +1,106 @@
+<!--[metadata]>
++++
+title = "Extending Engine with plugins"
+description = "How to add additional functionality to Docker with plugins extensions"
+keywords = ["Examples, Usage, plugins, docker, documentation, user guide"]
+[menu.main]
+parent = "engine_extend"
+weight=-1
++++
+<![end-metadata]-->
+
+# Understand Engine plugins
+
+You can extend the capabilities of the Docker Engine by loading third-party
+plugins. This page explains the types of plugins and provides links to several
+volume and network plugins for Docker.
+
+## Types of plugins
+
+Plugins extend Docker's functionality.  They come in specific types.  For
+example, a [volume plugin](plugins_volume.md) might enable Docker
+volumes to persist across multiple Docker hosts and a
+[network plugin](plugins_network.md) might provide network plumbing.
+
+Currently Docker supports volume and network driver plugins. In the future it
+will support additional plugin types.
+
+## Installing a plugin
+
+Follow the instructions in the plugin's documentation.
+
+## Finding a plugin
+
+The following plugins exist:
+
+* The [Blockbridge plugin](https://github.com/blockbridge/blockbridge-docker-volume)
+  is a volume plugin that provides access to an extensible set of
+  container-based persistent storage options. It supports single and multi-host Docker
+  environments with features that include tenant isolation, automated
+  provisioning, encryption, secure deletion, snapshots and QoS.
+
+* The [Convoy plugin](https://github.com/rancher/convoy) is a volume plugin for a
+  variety of storage back-ends including device mapper and NFS. It's a simple standalone
+  executable written in Go and provides the framework to support vendor-specific extensions
+  such as snapshots, backups and restore.
+
+* The [Flocker plugin](https://clusterhq.com/docker-plugin/) is a volume plugin
+  which provides multi-host portable volumes for Docker, enabling you to run
+  databases and other stateful containers and move them around across a cluster
+  of machines.
+
+* The [GlusterFS plugin](https://github.com/calavera/docker-volume-glusterfs) is
+  another volume plugin that provides multi-host volumes management for Docker
+  using GlusterFS.
+
+* The [IPFS Volume Plugin](http://github.com/vdemeester/docker-volume-ipfs)
+  is an open source volume plugin that allows using an
+  [ipfs](https://ipfs.io/) filesystem as a volume.
+
+* The [Keywhiz plugin](https://github.com/calavera/docker-volume-keywhiz) is
+  a plugin that provides credentials and secret management using Keywhiz as
+  a central repository.
+
+* The [Netshare plugin](https://github.com/gondor/docker-volume-netshare) is a volume plugin
+  that provides volume management for NFS 3/4, AWS EFS and CIFS file systems.
+
+* The [OpenStorage Plugin](https://github.com/libopenstorage/openstorage) is a cluster aware volume plugin that provides volume management for file and block storage solutions.  It implements a vendor neutral specification for implementing extensions such as CoS, encryption, and snapshots.   It has example drivers based on FUSE, NFS, NBD and EBS to name a few.
+
+* The [Quobyte Volume Plugin](https://github.com/quobyte/docker-volume) connects Docker to [Quobyte](http://www.quobyte.com/containers)'s data center file system, a general-purpose scalable and fault-tolerant storage platform.
+
+* The [REX-Ray plugin](https://github.com/emccode/rexray) is a volume plugin
+  which is written in Go and provides advanced storage functionality for many
+  platforms including VirtualBox, EC2, Google Compute Engine, OpenStack, and EMC.
+
+* The [Contiv Volume Plugin](https://github.com/contiv/volplugin) is an open
+  source volume plugin that provides multi-tenant, persistent, distributed storage
+  with intent based consumption using ceph underneath.
+
+* The [Contiv Networking](https://github.com/contiv/netplugin) is an open source
+  libnetwork plugin to provide infrastructure and security policies for a
+  multi-tenant micro services deployment, while providing an integration to
+  physical network for non-container workload. Contiv Networking implements the
+  remote driver and IPAM APIs available in Docker 1.9 onwards.
+
+* The [Weave Network Plugin](http://docs.weave.works/weave/latest_release/plugin.html)
+  creates a virtual network that connects your Docker containers -
+  across multiple hosts or clouds and enables automatic discovery of
+  applications. Weave networks are resilient, partition tolerant,
+  secure and work in partially connected networks, and other adverse
+  environments - all configured with delightful simplicity.
+
+* The [Kuryr Network Plugin](https://github.com/openstack/kuryr) is
+  developed as part of the OpenStack Kuryr project and implements the
+  Docker networking (libnetwork) remote driver API by utilizing
+  Neutron, the OpenStack networking service. It includes an IPAM
+  driver as well.
+
+## Troubleshooting a plugin
+
+If you are having problems with Docker after loading a plugin, ask the authors
+of the plugin for help. The Docker team may not be able to assist you.
+
+## Writing a plugin
+
+If you are interested in writing a plugin for Docker, or seeing how they work
+under the hood, see the [docker plugins reference](plugin_api.md).

vendor/github.com/hyperhq/hypercli/docs/extend/plugins_network.md

@@ -0,0 +1,57 @@
+<!--[metadata]>
++++
+title = "Docker network driver plugins"
+description = "Network driver plugins."
+keywords = ["Examples, Usage, plugins, docker, documentation, user guide"]
+[menu.main]
+parent = "engine_extend"
++++
+<![end-metadata]-->
+
+# Engine network driver plugins
+
+Docker Engine network plugins enable Engine deployments to be extended to
+support a wide range of networking technologies, such as VXLAN, IPVLAN, MACVLAN
+or something completely different. Network driver plugins are supported via the
+LibNetwork project. Each plugin is implemented asa  "remote driver" for
+LibNetwork, which shares plugin infrastructure with Engine. Effectively, network
+driver plugins are activated in the same way as other plugins, and use the same
+kind of protocol.
+
+## Using network driver plugins
+
+The means of installing and running a network driver plugin depend on the
+particular plugin. So, be sure to install your plugin according to the
+instructions obtained from the plugin developer.
+
+Once running however, network driver plugins are used just like the built-in
+network drivers: by being mentioned as a driver in network-oriented Docker
+commands. For example,
+
+    $ docker network create --driver weave mynet
+
+Some network driver plugins are listed in [plugins](plugins.md)
+
+The `mynet` network is now owned by `weave`, so subsequent commands
+referring to that network will be sent to the plugin,
+
+    $ docker run --net=mynet busybox top
+
+
+## Write a network plugin
+
+Network plugins implement the [Docker plugin
+API](https://docs.docker.com/extend/plugin_api/) and the network plugin protocol
+
+## Network plugin protocol
+
+The network driver protocol, in addition to the plugin activation call, is
+documented as part of libnetwork:
+[https://github.com/docker/libnetwork/blob/master/docs/remote.md](https://github.com/docker/libnetwork/blob/master/docs/remote.md).
+
+# Related Information
+
+To interact with the Docker maintainers and other interested users, see the IRC channel `#docker-network`.
+
+-  [Docker networks feature overview](../userguide/networking/index.md)
+-  The [LibNetwork](https://github.com/docker/libnetwork) project

vendor/github.com/hyperhq/hypercli/docs/extend/plugins_volume.md

@@ -0,0 +1,216 @@
+<!--[metadata]>
++++
+title = "Volume plugins"
+description = "How to manage data with external volume plugins"
+keywords = ["Examples, Usage, volume, docker, data, volumes, plugin, api"]
+[menu.main]
+parent = "engine_extend"
++++
+<![end-metadata]-->
+
+# Write a volume plugin
+
+Docker Engine volume plugins enable Engine deployments to be integrated with
+external storage systems, such as Amazon EBS, and enable data volumes to persist
+beyond the lifetime of a single Engine host. See the [plugin
+documentation](plugins.md) for more information.
+
+## Command-line changes
+
+A volume plugin makes use of the `-v`and `--volume-driver` flag on the `docker run` command.  The `-v` flag accepts a volume name and the `--volume-driver` flag a driver type, for example:
+
+    $ docker run -ti -v volumename:/data --volume-driver=flocker   busybox sh
+
+This command passes the `volumename` through to the volume plugin as a
+user-given name for the volume. The `volumename` must not begin with a `/`.
+
+By having the user specify a  `volumename`, a plugin can associate the volume
+with an external volume beyond the lifetime of a single container or container
+host. This can be used, for example, to move a stateful container from one
+server to another.
+
+By specifying a `volumedriver` in conjunction with a `volumename`, users can use plugins such as [Flocker](https://clusterhq.com/docker-plugin/) to manage volumes external to a single host, such as those on EBS.
+
+
+## Create a VolumeDriver
+
+The container creation endpoint (`/containers/create`) accepts a `VolumeDriver`
+field of type `string` allowing to specify the name of the driver. It's default
+value of `"local"` (the default driver for local volumes).
+
+## Volume plugin protocol
+
+If a plugin registers itself as a `VolumeDriver` when activated, then it is
+expected to provide writeable paths on the host filesystem for the Docker
+daemon to provide to containers to consume.
+
+The Docker daemon handles bind-mounting the provided paths into user
+containers.
+
+> **Note**: Volume plugins should *not* write data to the `/var/lib/docker/`
+> directory, including `/var/lib/docker/volumes`. The `/var/lib/docker/`
+> directory is reserved for Docker.
+
+### /VolumeDriver.Create
+
+**Request**:
+```json
+{
+    "Name": "volume_name",
+    "Opts": {}
+}
+```
+
+Instruct the plugin that the user wants to create a volume, given a user
+specified volume name.  The plugin does not need to actually manifest the
+volume on the filesystem yet (until Mount is called).
+Opts is a map of driver specific options passed through from the user request.
+
+**Response**:
+```json
+{
+    "Err": ""
+}
+```
+
+Respond with a string error if an error occurred.
+
+### /VolumeDriver.Remove
+
+**Request**:
+```json
+{
+    "Name": "volume_name"
+}
+```
+
+Delete the specified volume from disk. This request is issued when a user invokes `docker rm -v` to remove volumes associated with a container.
+
+**Response**:
+```json
+{
+    "Err": ""
+}
+```
+
+Respond with a string error if an error occurred.
+
+### /VolumeDriver.Mount
+
+**Request**:
+```json
+{
+    "Name": "volume_name"
+}
+```
+
+Docker requires the plugin to provide a volume, given a user specified volume
+name. This is called once per container start. If the same volume_name is requested
+more than once, the plugin may need to keep track of each new mount request and provision
+at the first mount request and deprovision at the last corresponding unmount request.
+
+**Response**:
+```json
+{
+    "Mountpoint": "/path/to/directory/on/host",
+    "Err": ""
+}
+```
+
+Respond with the path on the host filesystem where the volume has been made
+available, and/or a string error if an error occurred.
+
+### /VolumeDriver.Path
+
+**Request**:
+```json
+{
+    "Name": "volume_name"
+}
+```
+
+Docker needs reminding of the path to the volume on the host.
+
+**Response**:
+```json
+{
+    "Mountpoint": "/path/to/directory/on/host",
+    "Err": ""
+}
+```
+
+Respond with the path on the host filesystem where the volume has been made
+available, and/or a string error if an error occurred.
+
+### /VolumeDriver.Unmount
+
+**Request**:
+```json
+{
+    "Name": "volume_name"
+}
+```
+
+Indication that Docker no longer is using the named volume. This is called once
+per container stop.  Plugin may deduce that it is safe to deprovision it at
+this point.
+
+**Response**:
+```json
+{
+    "Err": ""
+}
+```
+
+Respond with a string error if an error occurred.
+
+
+### /VolumeDriver.Get
+
+**Request**:
+```json
+{
+    "Name": "volume_name"
+}
+```
+
+Get the volume info.
+
+
+**Response**:
+```json
+{
+  "Volume": {
+    "Name": "volume_name",
+    "Mountpoint": "/path/to/directory/on/host",
+  },
+  "Err": ""
+}
+```
+
+Respond with a string error if an error occurred.
+
+
+### /VolumeDriver.List
+
+**Request**:
+```json
+{}
+```
+
+Get the list of volumes registered with the plugin.
+
+**Response**:
+```json
+{
+  "Volumes": [
+    {
+      "Name": "volume_name",
+      "Mountpoint": "/path/to/directory/on/host"
+    }
+  ],
+  "Err": ""
+}
+```
+
+Respond with a string error if an error occurred.