WIP: Persistent disks proposal

This is a draft proposal for expanding GCEPersistentDisk to a fuller PersistentDisk framework.
That's not really a good model - pods shouldn't create other resources.  Resources either are referenced by a pod, or directly embedded.  Having the pod create volumes is a separation of concerns violation.

The flow needs to be

1. Volume is created
2. Pod is created that references volume (or embeds volume.status.mount)
3. Kubelet binds volume based on info in #1.

If the volume is not bind able, the kubelet has to go into a failure loop for that pod (like any other resource reference failure) and retry until the volume becomes available.


> On Dec 19, 2014, at 8:07 AM, Mark Turansky <notifications@github.com> wrote:
> 
> In docs/design/persistentdisks.md:
> 
> > +that don't belong to them.  Security is implemented via an access control list whereby an administrator specifies which usernames can access which namespaces.  
> > +
> > +## Behavior
> > +
> > +* PersistentDisk.Status.Mounts must be updated as disks are attached and detached from hosts.
> > +* NodePersistentDisks are never detached and remain in PersistentDisk.Status.Mounts until the disk is deleted.
> > +
> > +## Volumes Framework
> > +
> > +See [Tim Hockin's volumes framework](https://github.com/GoogleCloudPlatform/kubernetes/pull/2598)
> > +
> > +## <a name=schema></a>Schema
> > +
> > +* Add new top-level PersistentDisk REST object
> > +    * Disks have identity. Disks outlive pods. Their IDs must be persistent for future re-mounting.
> > +    * Disks requests are not expected to be POSTed to the API server.  
> Pod.Volume.PersisentDisk is where the request goes. After much go-around, the idea of having to post it first and then use it is not as elegant as requesting it where it is needed and having the API server create the disk object when it creates the pod object.
> 
> —
> Reply to this email directly or view it on GitHub.
>