WIP: Persistent disks proposal

This is a draft proposal for expanding GCEPersistentDisk to a fuller PersistentDisk framework.
Kubelet knows nothing about cloud providers, and every recent change we have made pushes cloud provider away from the core.  Cloud providers are monolithic interfaces that are too deeply embedded in the code to be flexible to extension, which is a core goal of Kube.  Instead, cloud providers can be implementations that controllers can run to mutate the system.  So having a CloudProviderVolumeController is fine, but it fails at handling multiple storage types so it can't be the only implementation.


> On Dec 19, 2014, at 7:59 AM, Mark Turansky <notifications@github.com> wrote:
> 
> In docs/design/persistentdisks.md:
> 
> > @@ -0,0 +1,197 @@
> > +# Persistent Disks
> > +
> > +## Abstract
> > +
> > +This document defines persistent, cluster-scoped storage for applications that require long lived data.  Developers will request storage as an intention ("I'd like 3gb of storage, please, with 3k min IOPS") and Kubernetes will use the configured cloud provider implementation to create, manage, and secure that storage.  Names for storage will vary by cloud provider, but each shall be known internally to Kubernetes as a disk. A new entity `PersistentDisk` is introduced to provide longevity to data that outlasts pods.
> I disagree re: Cloud Provider.
> 
> We need a strong interface/abstraction between the cluster and the infrastructure. We should code kubelet to the interface and it should be unaware of what the underlying provider is.
> 
> —
> Reply to this email directly or view it on GitHub.
>