torchbox / k8s-hostpath-provisioner Goto Github PK

I am testing the k8s-hostpath-provisioner, PVC remains in pending state.
Our system uses PSP so wondering if we need to apply any changes to allow serviceaccount access to hostpath?

[root@system~]# kubectl describe pvc test -n kube-system
Name: test
Namespace: kube-system
StorageClass: hostpath
Status: Pending
Volume:
Labels:
Annotations: volume.beta.kubernetes.io/storage-provisioner: torchbox.com/hostpath
Finalizers: [kubernetes.io/pvc-protection]
Capacity:
Access Modes:
VolumeMode: Filesystem
Events:
Type Reason Age From Message

Normal ExternalProvisioning 10s (x2 over 25s) persistentvolume-controller waiting for a volume to be created, either by external provisioner "torchbox.com/hostpath" or manually created by system administrator
Mounted By:

Thanks

Follow the instructions and the actual provisioner fails due to exec format error.

Docker image architecture says amd64.

First, thanks so much for this project: it does almost exactly what I need it to! I'm using it to provision non-networked local disk hostpath pvcs in a single-node cluster.

I would only like one new feature: the ability to limit the accessMode of the requesting pvc. This would make the storage class safer for my use case, by being able to specify which accessModes the storage class supports, and have the provisioner reject other accessModes.

Here is my desired YAML for my default (local disk) storage class, where I would like to reject ReadWriteMany and ReadOnlyMany accessModes:

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: local
  annotations:
    storageclass.kubernetes.io/is-default-class: "true"
provisioner: torchbox.com/hostpath
parameters:
  accessModes:
    - ReadWriteOnce
  pvDir: /volumes

This seems like an easy change, but I don't know Go well enough to send a pull request, and it's definitely not blocking my use of hostpath-provisioner.

Thanks again,
Michael.

Thank you very much for this provisioner. It's very helpful for us.

Unfortunately I've a problem with the reclaim policy. I've created two storage classes. One using reclaim policy delete and one retain. Getting the storage classes via kubectl shows the correct classes. After adding two volume claims (one for each class) both volumes use reclaim policy delete although the mapping to the storage class is correct.

To sum up: Storage classes are created using the correct reclaim policy. Creating Volumes from retain storage class always results in volumes with delete reclaim policy.