WIP: Persistent disks proposal

This is a draft proposal for expanding GCEPersistentDisk to a fuller PersistentDisk framework.
To be clear, I'm not against it being easy to normalize tiers.  I just believe any effort to bake that into the api that developers use will result in failure.  The goal of our project is to remove the need for most developers/ops from having to make decisions like this.  

I don't want storage with characteristics X/Y/Z - I want storage that is able to manage the io demand I place on it.  Looking to the future, we want a solution that lets the infrastructure improve the quality of service delivered to a particular volume *automatically*.  I spin up a db with medium load.  It starts growing slowly.  Eventually, an automated process automatically provisions / higher more storage in the backend, and starts mirroring that disk.  The ops guy gets an email - "your app is ready to move to the next tier of storage, you can swap to the new one by clinking this link." Or the slightly less awesome "do X, Y, and Z to move yourself."  Maybe you take downtime, maybe you don't.  But the story is that the infrastructure is taking care of these problems for you, because there is very little reason you should have to manage this yourself.

What's important is specifying criteria that are consistent across a number of environments.  


> On Dec 14, 2014, at 9:14 AM, Mark Turansky <notifications@github.com> wrote:
> 
> In docs/design/persistentdisks.md:
> 
> > +
> > +AWS EBS mapping to internal types:
> > +
> > +    fastest:    'io1' for Provisioned IOPS (SSD) volumes 
> > +    faster:      'gp2' for General Purpose (SSD) volumes
> > +    fast:       'standard' for Magnetic volumes  (default)
> > +
> > +GCE disk mapping to internal types:
> > +
> > +    fastest:    'pd-ssd' for solid-state drives
> > +    faster:     'pd-standard' for hard disk (defaut)
> > +    fast:       'pd-standard' -- there is no 3rd option for GCE
> > +    
> > +NFS disk mapping to internal types:
> > +
> > +    fastest:    'nodeLocal' for node local storage
> @smarterclayton correct, there is no "local+shared" disk, but there could be two types of storage (based on perf) from the provider. Just as EBS has 3 types, I was thinking our "enterprise provider" (for lack of a better term) could offer two types: local and attached (node local and nfs). But that also means anyone using that provider is now required to use an NFS server, which might not be correct for their environment.
> 
> Cloud providers are easy to write for, but a heterogeneous enterprise customer is more difficult. I believe the correct solution is to make it easy to customize the storage provider per environment. A little bit of Spring dependency-injection type of configuration would be lovely. Let the admin configure the environment and allow devs to request normalized types of disks.
> 
> —
> Reply to this email directly or view it on GitHub.
>