Why: speed up e2e tests
How: https://onsi.github.io/ginkgo/#parallel-specs

In order to install the provisioner in clusters which have PodSecurityPolicy in effect, a policy fulfilling the configured security contexts is required

To replicate:

clone repo

helm template -f ./helm/examples/gce-retain.yaml ./helm/provisioner/ >> hello.yaml

look at storage class reclaim policy.

from: https://github.com/kubernetes-incubator/external-storage/tree/master/local-volume

• import commits (local-volume only) from external-storage repo (git filter-branch --prune-empty --subdirectory-filter local-volume)
• rebase on new master
• update README.md
• update go import path
• vendor dependencies by dep
• write new Makefile and hack scripts
• write new .travis.yaml

Original issue: kubernetes-retired/external-storage#950

• Add e2e framework
• Copy current e2e tests from k/k, refer kubernetes-retired/external-storage#1058

/assign

I just ran this on a new GKE cluster (1.12.5-gke.5 without RBAC) and while it appears that the PVs are all created correctly, each pod logs out an error every 10 seconds saying that Path "/mnt/disks/by-uuid" is not an actual mountpoint. Is that something I need to be worried about causing data integrity problems?

It feels like it's probably iterating the by-uuid directory to get the disks, but not excluding the parent directory from the iteration.

logs on all DaemonSet pods

common.go:316] StorageClass "local-scsi" configured with MountDir "/mnt/disks", HostDir "/mnt/disks", VolumeMode "Filesystem", FsType "", BlockCleanerCommand ["/scripts/quick_reset.sh"]
main.go:60] Loaded configuration: {StorageClassConfig:map[local-scsi:{HostDir:/mnt/disks MountDir:/mnt/disks BlockCleanerCommand:[/scripts/quick_reset.sh] VolumeMode:Filesystem FsType:}] NodeLabelsForPV:[] UseAlphaAPI:false UseJobForCleaning:false MinResyncPeriod:{Duration:5m0s} UseNodeNameOnly:true}
main.go:61] Ready to run...
common.go:378] Creating client using in-cluster config
main.go:82] Starting controller
main.go:96] Starting metrics server at :8080
controller.go:45] Initializing volume cache
cache.go:55] Added pv "local-pv-a1e255f1" to cache
cache.go:55] Added pv "local-pv-18439af4" to cache
cache.go:55] Added pv "local-pv-df57f635" to cache
cache.go:55] Added pv "local-pv-6384a96b" to cache
cache.go:55] Added pv "local-pv-1e0913d8" to cache
cache.go:55] Added pv "local-pv-709ace0e" to cache
cache.go:55] Added pv "local-pv-2d4262cf" to cache
cache.go:55] Added pv "local-pv-d216f352" to cache
controller.go:108] Controller started
discovery.go:269] Path "/mnt/disks/by-uuid" is not an actual mountpoint
discovery.go:269] Path "/mnt/disks/by-uuid" is not an actual mountpoint
...
---
(repeats every 10 seconds forever)
discovery.go:269] Path "/mnt/disks/by-uuid" is not an actual mountpoint
---

---
(repeats every 10 minutes forever)
cache.go:64] Updated pv "local-pv-a1e255f1" to cache
cache.go:64] Updated pv "local-pv-1e0913d8" to cache
cache.go:64] Updated pv "local-pv-709ace0e" to cache
cache.go:64] Updated pv "local-pv-18439af4" to cache
cache.go:64] Updated pv "local-pv-df57f635" to cache
cache.go:64] Updated pv "local-pv-2d4262cf" to cache
cache.go:64] Updated pv "local-pv-d216f352" to cache
cache.go:64] Updated pv "local-pv-6384a96b" to cache
---

helm generated yaml

---
# Source: provisioner/templates/provisioner.yaml
apiVersion: v1
kind: ConfigMap
metadata:
  name: local-provisioner-config
  namespace: local-volume-provisioner
  labels:
    heritage: "Tiller"
    release: "release-name"
    chart: provisioner-2.3.0
data:
  useNodeNameOnly: "true"
  storageClassMap: |
    local-scsi:
       hostDir: /mnt/disks
       mountDir: /mnt/disks
---
apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: local-volume-provisioner
  namespace: local-volume-provisioner
  labels:
    app: local-volume-provisioner
    heritage: "Tiller"
    release: "release-name"
    chart: provisioner-2.3.0
spec:
  selector:
    matchLabels:
      app: local-volume-provisioner
  template:
    metadata:
      labels:
        app: local-volume-provisioner
    spec:
      serviceAccountName: local-storage-admin
      nodeSelector:
        cloud.google.com/gke-local-ssd: "true"
      tolerations:
        - operator: Exists
      containers:
        - image: "quay.io/external_storage/local-volume-provisioner:v2.3.0"
          name: provisioner
          securityContext:
            privileged: true
          env:
          - name: MY_NODE_NAME
            valueFrom:
              fieldRef:
                fieldPath: spec.nodeName
          - name: MY_NAMESPACE
            valueFrom:
              fieldRef:
                fieldPath: metadata.namespace
          - name: JOB_CONTAINER_IMAGE
            value: "quay.io/external_storage/local-volume-provisioner:v2.3.0"
          volumeMounts:
            - mountPath: /etc/provisioner/config
              name: provisioner-config
              readOnly: true
            - mountPath: /dev
              name: provisioner-dev
            - mountPath: /mnt/disks
              name: local-scsi
              mountPropagation: "HostToContainer"
      volumes:
        - name: provisioner-config
          configMap:
            name: local-provisioner-config
        - name: provisioner-dev
          hostPath:
            path: /dev
        - name: local-scsi
          hostPath:
            path: /mnt/disks

Migrating from kubernetes-retired/external-storage#786
/kind cleanup

• build, tag and test container image
• Update changelog
• Update helm
• git tag

/assign

Hi,
I need to configure the local-storage-provisioner for an arm cluster, but the quay.io/external_storage/local-volume-provisioner image does not work on arm devices.
Is it possible to do that? And, if it is, how? Can I get the Dockerfile to change the base image or exists any image for that? Thanks.

Feature Request:

It would be nice be able to use the helm chart from the official incubator/stable repository of helm - https://github.com/helm/charts.

Being able to run helm install local-static-provisioner -f myconfig.yaml is more convenient than checking out the code and running numerous helm/kubectl commands to install the local static provisioner.

Migrating from kubernetes-retired/external-storage#817

/kind feature

Migrating from kubernetes-retired/external-storage#1011
/kind feature

I follow the steps，
mkdir
kubectl create -f deployment/kubernetes/example/default_example_storageclass.yaml
helm template ./helm/provisioner > deployment/kubernetes/provisioner_generated.yaml
kubectl create -f deployment/kubernetes/provisioner_generated.yaml
kubectl get pv
but here show
No resources found.

There are (at least) three StorageClass names for local volume:

• fast-disks
• local-fast
• local-storage

Is it better to have only one StorageClass name? If so, which is better?
I am glad to submit a PR to fix this.

suggested by @msau42

• raid support (#65)
• configure LVM and pre-create block/fs volumes (suggested by @gregwebs)

GKE-specific:

• delete local PV object is the volume is permanently deleted (pingcap/tidb-operator#408 (comment))

Why:

• simpler
• newbie friendly

e.g.

• /provisioner/cmd -> /cmd/local-volume-provisioner
• /utils/ -> cmd/utils/
• merge /provisioner/Makefile with /Makefile
• put some docs under docs/ (new) directory
  • /provisioner/README.md -> /docs/Provisioner.md
  • /provisioner/RELEASE.md -> /docs/RELEASE.md
  • /provisioner/TODO.md -> /TODO.md
• /provisioner/deployment -> /deployment
• /provisioner/pkg -> /pkg

cc @msau42 What do you think?

Testgrid: https://testgrid.k8s.io/sig-storage-local-static-provisioner#master-gke-default
Example: https://prow.k8s.io/view/gcs/kubernetes-jenkins/logs/ci-sig-storage-local-static-provisioner-master-gke-default/415
Reason: Cannot create local-storage-provisioner-jobs-role role object at here.

Error log:

/home/prow/go/src/sigs.k8s.io/sig-storage-local-static-provisioner/test/e2e/e2e_test.go:285
Expected error:
    <*errors.StatusError | 0xc0010401b0>: {
        ErrStatus: {
            TypeMeta: {Kind: "", APIVersion: ""},
            ListMeta: {SelfLink: "", ResourceVersion: "", Continue: ""},
            Status: "Failure",
            Message: "roles.rbac.authorization.k8s.io \"local-storage-provisioner-jobs-role\" is forbidden: attempt to grant extra privileges: [{[*] [batch] [jobs] [] []}] user=&{[email protected]  [system:authenticated] map[user-assertion.cloud.google.com:[AKUJVpl4/VP79aN4mEN2QMVLDAeQd9+ylFX4ocaQzWfRhRPqnBr/tP3SpvcSYE2Bm/aMNmf2pXrS7dt3YuI8/Q6vMXPg8apHgE0qGKmVUnzY9KafsDuqlVRANQiTCsYjZefCU3txWYR8hLxO1rJ90aOYyDBkACBY9BnWYNNOEpEOYvx8xlB7EWjNXo97N9LhH8vv3QvjEY6kQwsL+FVKRnttwoNCbUfBWQ+OSYNKOpCik9FE6fITqL2mprhdxcHfBuE0wyzmV/W/j9XNpAlt6ojE1s5+]]} ownerrules=[{[create] [authorization.k8s.io] [selfsubjectaccessreviews selfsubjectrulesreviews] [] []} {[get] [] [] [] [/api /api/* /apis /apis/* /healthz /openapi /openapi/* /swagger-2.0.0.pb-v1 /swagger.json /swaggerapi /swaggerapi/* /version /version/]}] ruleResolutionErrors=[]",
            Reason: "Forbidden",
            Details: {
                Name: "local-storage-provisioner-jobs-role",
                Group: "rbac.authorization.k8s.io",
                Kind: "roles",
                UID: "",
                Causes: nil,
                RetryAfterSeconds: 0,
            },
            Code: 403,
        },
    }
    roles.rbac.authorization.k8s.io "local-storage-provisioner-jobs-role" is forbidden: attempt to grant extra privileges: [{[*] [batch] [jobs] [] []}] user=&{[email protected]  [system:authenticated] map[user-assertion.cloud.google.com:[AKUJVpl4/VP79aN4mEN2QMVLDAeQd9+ylFX4ocaQzWfRhRPqnBr/tP3SpvcSYE2Bm/aMNmf2pXrS7dt3YuI8/Q6vMXPg8apHgE0qGKmVUnzY9KafsDuqlVRANQiTCsYjZefCU3txWYR8hLxO1rJ90aOYyDBkACBY9BnWYNNOEpEOYvx8xlB7EWjNXo97N9LhH8vv3QvjEY6kQwsL+FVKRnttwoNCbUfBWQ+OSYNKOpCik9FE6fITqL2mprhdxcHfBuE0wyzmV/W/j9XNpAlt6ojE1s5+]]} ownerrules=[{[create] [authorization.k8s.io] [selfsubjectaccessreviews selfsubjectrulesreviews] [] []} {[get] [] [] [] [/api /api/* /apis /apis/* /healthz /openapi /openapi/* /swagger-2.0.0.pb-v1 /swagger.json /swaggerapi /swaggerapi/* /version /version/]}] ruleResolutionErrors=[]
not to have occurred
/home/prow/go/src/sigs.k8s.io/sig-storage-local-static-provisioner/test/e2e/e2e_test.go:540

Migrating from kubernetes-retired/external-storage#701

Right now everything is manual: creating/pushing containers, updating docs/examples, etc.

At least creating/pushing containers + e2es can be automated with CI.

Migrating issue from: kubernetes-retired/external-storage#1052

/help

/assign

The directory for the pod does not get created. Have to create the directory manually on the node.

FailedMount | MountVolume.SetUp failed for volume "local-pv-3a82f760" : mount failed: exit status 32 Mounting command: mount Mounting arguments: -o bind /mnt/disks/disk1 /var/lib/kubelet/pods/27153f2b-7664-11e9-95b0-000af7854ba0/volumes/kubernetes.io~local-volume/local-pv-3a82f760 Output: mount: special device /mnt/disks/disk1 does not exist

FIX

mkdir /var/lib/kubelet/pods/27153f2b-7664-11e9-95b0-000af7854ba0/volumes/kubernetes.io~local-volume/local-pv-3a82f760

hack/run-e2e.sh will update docker configuration via gcloud auth configure-docker, but DOCKER_CONFIG in release job is for quay.io and read-only mounted.

https://github.com/client9/misspell

We mount /dev into pod for device discovery, it has conflicts when docker --init flag is enabled because docker will mount init at /dev/init.

I reported this issue to moby project (moby/moby#37645) and it is fixed in moby/moby#37665. But it takes some time for this to be fixed in docker CE/EE.

Workarounds:

• do not use docker --init
• do not mount /dev, but local volume provisioner will not discovery newly mounted devices, see kubernetes-retired/external-storage#783 (comment)

It may have better workaround, but I don't have time to investigate.

• copy all local volume provisioner e2e tests from k/k repo (#31)
• clean up local provisioner e2e tests in k/k repo (kubernetes/kubernetes#72617)

/assign

e2e tests from k/k repo:

• Local volume provisioner [Serial] should create and recreate local persistent volume
• Local volume provisioner [Serial] should not create local persistent volume for filesystem volume that was not bind mounted
• Local volume provisioner [Serial] should discover dynamically created local persistent volume mountpoint in discovery directory
• Stress with local volume provisioner [Serial] should use be able to process many pods and reuse local volumes (done in #31)

I am struggling to get this running. Im following these instructions

https://docs.openshift.com/container-platform/3.11/install_config/configuring_local.html

I got everything done, but when the pod attempts to start, i get this error.

F0312 02:19:33.183835 1 main.go:115] Could not get node information: nodes "okdtest.panasas.com" is forbidden: User "system:serviceaccount:default:panfs-storage-admin" cannot get nodes at the cluster scope: no RBAC policy matched

what am i missing?

also, it can print version with -v flag is provided.

It helps to detect the version of the running program.

github.com/kubernetes-sigs -> sigs.k8s.io

/assign

• fmt
• lint
  • verify-gometalinter.sh in repo-infra is too strict, I think golint is enough
• vet
• boilerplate
• vendor files

Reuse https://github.com/kubernetes/repo-infra when possible.

In most cases, node name as provisioner name is better.

xref:

• kubernetes-retired/external-storage#945
• https://github.com/kubernetes-sigs/sig-storage-local-static-provisioner/blob/master/docs/faqs.md#pv-with-delete-reclaimpolicy-is-released-but-not-going-to-be-reclaimed

For context, this issue stems from a Slack conversation with @msau42 that we wanted to capture here.

It would be awesome if the local static provisioner could support RAID'ing devices together.

Currently, if a user wants to RAID local disks together they must do so manually before presenting the provisioner with a filesystem or block device. Some ways this can currently be achieved include but are not limited to:

1. Constructing the RAID volume at node provisioning time and passing formatting it to the provisioner as an FS, or as block device.
2. Using an init container to the local static provisioner that RAIDs disks together, either as block devices or after dismantling FS's (this was @msau42's idea).
3. Using some other process to accomplish RAID'ing/formatting, and then labeling nodes that have been set up and using NodeAffinity to only run the local provisioner on those nodes.

Option (1) is unfortunately not suitable for managed Kubernetes platforms where the only knobs the user have may be how many local FS/block volumes they want, and not how they're formatted. The other options have the benefit of potentially being compatible with a managed platform, however they require manual intervention from the user. Many of these goals may be accomplished with the LVM provisioner, but it sounds like that might be far off enough to warrant work in the meantime.

If it aligns with the goals of the local static provisioner, it would be really helpful if the provisioner could handle being presented with block devices and RAID'ing (and potentially formatting) them before creating the PV. To relax the constraint of requiring block devices maybe this same functionality could eventually include deconstructing FS's as well. I noticed "Local block devices as a volume source, with partitioning and fs formatting" is on the roadmap so maybe this could fit in there?

I wanted to start this issue as a place to discuss some of these issues. If we can reach consensus on how to proceed I'd be happy to help contribute.

Migrating from kubernetes-retired/external-storage#739
/kind feature

To simplify administration, it would be helpful to have a friendly name embedded in the generated PV's name.

This could be accomplished by adding the mount point/device name before the checksum.

For example, the following PV:

Labels:            <none>
Annotations:       pv.kubernetes.io/provisioned-by: local-volume-provisioner-dev-b7cb269c-21f6-11e9-8d64-000c291c888b
Finalizers:        [kubernetes.io/pv-protection]
StorageClass:      hdd
Status:            Available
Claim:
Reclaim Policy:    Retain
Access Modes:      RWO
VolumeMode:        Filesystem
Capacity:          19Gi
Node Affinity:
  Required Terms:
    Term 0:        kubernetes.io/hostname in [dev]
Message:
Source:
    Type:  LocalVolume (a persistent volume backed by local storage on a node)
    Path:  /mnt/disks/gitlab
Events:    <none>

would become local-pv-gitlab-27f18fc5

This shouldn't cause any problems, as the name is already used to generate the checksum - any changes in filename would already cause a change in PV name.

so priorityClassname can only be run in the kube-system namespace. if they specify any other namespace it fails. The template should check for a conditional, or straight up remove it (which I think would be best, considering its on the chopping block for .14 and beyond).

the offending line is here
https://github.com/kubernetes-sigs/sig-storage-local-static-provisioner/blob/master/helm/provisioner/templates/provisioner.yaml#L67

The cleanup job of block devices returns error "/mnt/kubernetes/vol_10g_b is not a block device.", and PV remains stuck in "Released" state.

Error is triggered by validateBlockDevice function in the cleanup pod (local-volume-provisioner:v2.3.0).
This pod is correctly mounting /mnt/kubernetes (mountPath), but not mounting /dev, hence the symlinks are invalid.

Creating and using the local volumes works, because local-volume-provisioner job does mount /dev.

kubectl get jobs -n kube-system cleanup-local-pv-4579e45f -o yaml
apiVersion: batch/v1
kind: Job
-- snip -- 
  name: cleanup-local-pv-4579e45f
  namespace: kube-system
-- snip -- 
      containers:
      - command:
        - /scripts/quick_reset.sh
        env:
        - name: LOCAL_PV_BLKDEVICE
          value: /mnt/kubernetes/vol_10g_b
        image: quay.io/external_storage/local-volume-provisioner:v2.3.0
        imagePullPolicy: IfNotPresent
        name: cleaner
        resources: {}
        securityContext:
          privileged: true
          procMount: Default
        terminationMessagePath: /dev/termination-log
        terminationMessagePolicy: File
        volumeMounts:
        - mountPath: /mnt/kubernetes
          name: mount-25626bfb
  -- snip -- 
      volumes:
      - hostPath:
          path: /mnt/kubernetes
          type: ""
        name: mount-25626bfb
-- snip -- 

kubectl get pods -n kube-system local-volume-provisioner-pjwsg -o yaml
apiVersion: v1
kind: Pod
-- snip -- 
  name: local-volume-provisioner-pjwsg
  namespace: kube-system
-- snip -- 
    image: quay.io/external_storage/local-volume-provisioner:v2.3.0
    imagePullPolicy: IfNotPresent
    name: provisioner
-- snip -- 
    securityContext:
      privileged: true
      procMount: Default
-- snip -- 
    volumeMounts:
    - mountPath: /etc/provisioner/config
      name: provisioner-config
      readOnly: true
    - mountPath: /dev
      name: provisioner-dev
    - mountPath: /mnt/kubernetes
      mountPropagation: HostToContainer
      name: local-disks
    - mountPath: /var/run/secrets/kubernetes.io/serviceaccount
      name: local-storage-admin-token-wwp9b
      readOnly: true
-- snip -- 
  volumes:
  - configMap:
      defaultMode: 420
      name: local-provisioner-config
    name: provisioner-config
  - hostPath:
      path: /dev
      type: ""
    name: provisioner-dev
  - hostPath:
      path: /mnt/kubernetes
      type: ""
    name: local-disks
  - name: local-storage-admin-token-wwp9b
    secret:
      defaultMode: 420
      secretName: local-storage-admin-token-wwp9b
-- snip -- 

Bug is even in the autogen example:

https://github.com/kubernetes-sigs/sig-storage-local-static-provisioner/blob/master/helm/generated_examples/baremetal-prometheus.yaml#L122

Its just indented 4 spaces too many.

Purpose: help user to configure local volume static provisioner to discover local SSDs in an interactive way
How: https://cloud.google.com/shell/docs/tutorial
Related docs: https://cloud.google.com/kubernetes-engine/docs/how-to/persistent-volumes/local-ssd

Current:

• pull-sig-storage-local-static-provisioner
  • make
• pull-sig-storage-local-static-provisioner-verify
  • make verify
• pull-sig-storage-local-static-provisioner-test
  • make test

After e2e tests are done:

• pull-sig-storage-local-static-provisioner-e2e
  • make e2e

/assign

Migrating from kubernetes-retired/external-storage#958
/assign

• dump cluster logs
• dump provisioner logs

Without logs, it's hard to debug failures.

Motivation

Able to migrate PVs (actually underlying volumes) to another storage class and do not be afraid volumes can possibly be discovered more than once.

Problem

Current PV name (generated from path + class + node) is used as a unique identifier for the path on the node. It has some drawbacks, e.g. cannot change PV naming convention anymore, and users cannot change the storage class name, otherwise, volumes will be discovered again.

For example, at first, a user creates a storage class foo to discovery volumes under /mnt/disks, but find foo name is not a good name and want to change it or simply changed the configuration by accident, volumes under /mnt/disks will be discovered again and new PVs with same paths will be created. Pods which expect to use different PVs under different storage class may mount the same volume.

Solution

• Check PV.spec.path and PV.nodeAffinity, if there is a matching PV in PV cache, skip discovering it
• A discovery path can be configured under more than one storage class, but only one can be enabled for discovering
  • Note that all storage classes are able to be enabled for deleting

Benefits:

• Do not depend on PV name, we can use any naming mechanism in future
• It helps the user to migrate volumes to new storage class

Use cases

Name of storage class is changed by accident

In the beginning, alice as system admin uses the following configuration for provisioner:

    foo:
      hostDir: /mnt/disks
      mountDir: /mnt/disks

Some volumes are discovered for storage class foo. Alice changes the storage class name to bar in provisioner configuration:

    bar:
      hostDir: /mnt/disks
      mountDir: /mnt/disks

Volumes under storage class foo will not be created under storage class bar. Only new volumes added in /mnt/disks will be created.

This is safer than the current behavior.

Note that, old volumes under storage class foo cannot be deleted by provisioner in this scenario because current provisioner will skip if storage class is not found in its configuration. (For in-process deleting, provisioner has no way to know mount path in provisioner container without storage class configuration) However, users can add old configuration back to recover deletion.

Migrate volumes to new storage class

In the beginning, alice as system admin uses the following configuration for provisioner:

    foo:
      hostDir: /mnt/disks
      mountDir: /mnt/disks

Alice wants to migrate volumes under /mnt/disks to another storage class bar, she can add a new storage class:

    foo:
      hostDir: /mnt/disks
      mountDir: /mnt/disks
      disabledForDiscovery: true # only one storage class for same `hostDir` can be active for discovery (default)
    bar:
      hostDir: /mnt/disks
      mountDir: /mnt/disks

Provisioner now can discover new volumes from /mnt/disks under storage class bar.

When volumes under foo are released and marked persistentVolumeReclaimPolicy=Delete, they will be deleted by provisioner.

When all volumes under foo are deleted, foo storage class can be removed from provisioner configuration. Of course, this is optional.

    bar:
      hostDir: /mnt/disks
      mountDir: /mnt/disks

Decide if 2.3.1 or 2.4.0. Taking a quick glance at the commits, it was mostly release tooling and helm chart fixes that went in. cc @cofyc if there was something major I missed.

/assign

Is this repo the right place to submit a PR with dynamic local volume provisioning?
I read in the documentation that dynamic provisioning is on the roadmap, but wanted to double check because the name of the repo has "static" in it which doesn't look like a good omen.

xref: #21 (comment)

Why: simpler
How: kubernetes/kubernetes#74391

In addition to getting start documentation, we need to some operation docs to guide users to operate in the production cluster.

• Deleting/removing the underlying volume: https://github.com/kubernetes-sigs/sig-storage-local-static-provisioner#deletingremoving-the-underlying-volume
  • https://github.com/kubernetes-sigs/sig-storage-local-static-provisioner#managing-your-local-volumes
• deployment issue when docker --init flag is enabled (#50)
• ways to prepare disks in production
  • https://github.com/kubernetes-sigs/sig-storage-local-static-provisioner#managing-your-local-volumes
• How to fix when a PV (reclaimPolicy=Delete) is released but not able to be deleted
• do not delete PV to recycle volume
  • provisioner has no reliable way to know whether volume without a matching PV has been used before, so it will not clean up it
• How to upgrade provisioner configuration (related to #12)
• How to migrate volumes to another storage class (depends on #75)

Think after single-node cluster e2e test is done.

Travis job has following resource limitations:

• Cores: 2
• Memory: 7.5G
• Disk: < 18G
• Stdout Log Limit: 4MB
• Timeout: 2 Hours

Why: #62, #93

Test cases:

• pod security policy when PodSecurityPolicy admission control is in effect