WIP: Persistent disks proposal

This is a draft proposal for expanding GCEPersistentDisk to a fuller PersistentDisk framework.


----- Original Message -----
> > +
> > +* NFS shares will not be created dynamically
> > +    * The system administrator will create, format, and export NFS shares
> > into a pool.
> > +    * Scripts will be provided to make this task easier for admins.
> > +    * Responsibility for keeping the pool full is left to the
> > administrator.
> > +* NodePersistentDisk can crash a host
> > +    * Without quotas in place, any pod can fill the filesystem via an
> > EmptyDir, HostDir, or NodePersistentDisk.
> > +    * A filesystem like XFS provides project quotas.
> > + * All disks are considered "new" in Kubernetes
> > + 	* Migrating legacy data is not in scope
> > + 	* Existing named disks are supported by administrative action (adding
> > disk objects in etcd)
> > +
> > +
> > +## Size and Performance -- Requesting a disk
> > +
> > +A storage request is made using the API where only intent is expressed
> > (size and performance).  Kubernetes handles creating, attaching/mounting,
> > deleting, and otherwise managing the disk.
> 
> What do you suggest for the first iteration of storage?
> 
> Do we expose the underlying provider (or otherwise expect a pod author to
> know it -- a leaky abstraction) and require the actual constant values used
> in API calls?  Or do we attempt normalize them across all providers to plug
> the leak?

Resources define constraints.  Constraints have minimums, maximums, and in the absence of those the system will provide the right behavior.  Just because you say "I want X" doesn't mean you're going to get X - it just means someone is going to give you the thing that looks closest to X.

Why would we normalize them?  The values I mentioned certainly have real behavior.  The first and most useful is "minimum size".