gistfile1.md

I'm trying to extend/replace this gist with: https://docs.google.com/presentation/d/1vCx8WfkPPYi6_SJ4s41ocUzF-Zc3M2vBrY5Ynh9ZbG8/edit?usp=sharing

Given the following in the apiserver:

Storage Class API Objects

- apiVersion: v1
  kind: storageClass
  metadata:
    labels:
      class: gold
    name: Gold_Card
  spec:
    description: This class comes with Eric's magic golden secret sauce which is fast, cheap, reliable, and makes good fried chicken!

- apiVersion: v1
  kind: storgageClass
  metadata:
    labels:
      class: silver
      group: legal
    name: Legal_Silver_Storage
  spec:
    description: This class is silver and should be used by legal since it is encrypted on disk.

- apiVersion: v1
  kind: storageClass
  metadata:
    labels:
      class: silver
      group: sales
    name: Sales_Silver_Storage
  spec:
    description: This calss is silver and should be used by sales since it allows easy sharing with support.

Persistent Volume API Objects

- apiVersion: v1
  kind: PersistentVolume
  metadata:
    name: pv0001
    labels:
      class: gold
      server: 172.17.0.2
  spec:
    nfs:
      path: /goldpath
      server: 172.17.0.2

- apiVersion: v1
  kind: PersistentVolume
  metadata:
    name: pv0002
    labels:
      class: silver
      group: sales
      server: 172.17.0.2
  spec:
    nfs:
      path: /silversales
      server: 172.17.0.2

- apiVersion: v1
  kind: PersistentVolume
  metadata:
    name: pv0003
    labels:
      class: silver
      group: sales
      server: 172.17.0.3
  spec:
    nfs:
      path: /silver3
      server: 172.17.0.3

A developer/user can learn about the system by doing:

$ kubectl describe storageclasses

Name:          Gold_Card
Labels:        class=gold
Description:   This class comes with Eric's magic golden secret sauce which is fast, cheap, reliable, and makes good fried chicken!
Available PVs: 1

Name:          Legal_silver_storage
Labels:        class=silver,group=legal
Description:   This class is silver and should be used by legal since it is encrypted on disk.
Available PVs: 0

Name:          Sales_Silver_Storage
Labels:        class=silver,group=sales
Description:   This calss is silver and should be used by sales since it allows easy sharing with support.
Available PVs: 2

To use this information the user would create:

kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: mygoldclaim
spec:
  selector:
    class: gold

Notice the 'selector' on the PVC is merely a copy/paste from the StorageClass Object. But the actual selector is between the PVC and PV. The StorageClass for manually provisioned PVs is ENTIRELY descriptive. It serves NO function except a way to describe and learn about PVs.

And would get bound to pv0001

---

If a developer were to create the following

kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: mylessspecificlcaim
spec:
  selector:
    class: silver

Then they may be bound to pv0002 or pv0003

---

But if they created the following

kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: mylessspecificlcaim
spec:
  selector:
    class: silver
    group: sales
    server: 172.17.0.3

They would only get bound to pv0003

=========

Now lets talk Dynamic Provisioning

A dynamic provisioned storage class is going to require some extra info! Its object might look something like (completely made up and completely up for discussion):

- apiVersion: v1
  kind: storageClass
  metadata:
    labels:
      class: GoGo
      group: IT
    name: MagicMike
  spec:
    description: This class is amazing and creates its own PVs!
    dynamic_provisoner:
      - binary_name: /opt/makeit!
        args: "labels="class=GoGo,group=IT" zone=east"

If a devel runs:

$ kubectl describe storageclasses

Name:          MagicMike
Labels:        class=GoGo,group=IT
Description:   This class is amazing and creates its own PVs!
PVs are dynamically provisioned

And if they listed PVs they wouldn't see any!

---

If a developer/user creates:

kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: justCallGoGoAlready
spec:
  selector:
    class: GoGo

The system will match on the StorageClass MagicMike (that's how label selectors work) and will then provision a PV like:

- apiVersion: v1
  kind: PersistentVolume
  metadata:
    name: pvgenmagicmike0001
    labels:
      class: GoGo
      group: IT
  spec:
    nfs:
      path: something
      server: something.something.something

And the PVC would be bound to this PV

WIN!

If the user did the label selector wrong

kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: justCallGoGoAlready
spec:
  selector:
    class: GoGo
    group: sales

This would not match on ANY StorageClass or PersistentVolume and could thus never be satisfied.

For brevity Resources and AccessMode were left out of all object representations. However these must also be satisfied.