WIP: Persistent disks proposal

This is a draft proposal for expanding GCEPersistentDisk to a fuller PersistentDisk framework.
The point of the proposal (at the core) is that you are specifying constraints.  Fast/faster/fastest are meaningless across enterprise clusters and an online space, because any of them can change outside of control at any time.

Example: tomorrow IaaS provider A launches *super duper fast storage*, pushes all their tiers down one, and eliminates the slowest tier.  Is fastest still comparable to another provider?  No.

Applications define what they *need*.  I don't need "fastest", I need "enough iops, bandwidth, and latency" to run 10k writes per second.  I should not have to ask for ssd, but I can specify criteria which correspond to ssds.  Relative measurements are not the application managers concern, they are the infrastructures.  We don't need to solve anything beyond gross matching now, which can be almost entirely defined by simple heuristics.


> On Dec 14, 2014, at 9:07 AM, Mark Turansky <notifications@github.com> wrote:
> 
> In docs/design/persistentdisks.md:
> 
> > +
> > +* 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.
> @smarterclayton good feedback overall. thanks.
> 
> AWS offers exactly 3 types of EBS volumes for performance, GCE PD has 2, and NFS shares are completely beyond our control. Local node storage performance is dependent entirely on the disk and filesystem used on the node. Durability and HA is dependent on the provider of the storage.
> 
> I attempted to normalize the different types of performance so that requests for storage don't have to know the underlying types (a leaky abstraction).
> 
> Please let me know how we can achieve what you're asking, because I cannot see it today and certainly not for the first version of storage.
> 
> —
> Reply to this email directly or view it on GitHub.
>