(I've filed this against CNV because we're using the hostpath provisioner.)

Description of problem:

If I create a persistent volume claim using the hostpath provisioner:

---
kind: PersistentVolumeClaim
apiVersion: v1
metadata:
  name: lars-test-pvc
  namespace: default
spec:
  accessModes:
    - ReadWriteOnce
  resources:
    requests:
      storage: 1Gi
  storageClassName: hostpath-provisioner
  volumeMode: Filesystem

And then create a pod that consumes that claim:

---
apiVersion: "v1"
kind: "Pod"
metadata:
  name: "lars-test-pod"
  namespace: default
spec:
  containers:
    - name: "lars-test-web"
      image: "nginx"
      ports:
        - containerPort: 80
          name: "http-server"
      volumeMounts:
        - mountPath: "/var/www/html"
          name: "pvol"
  volumes:
    - name: "pvol"
      persistentVolumeClaim:
        claimName: "lars-test-pvc"

Everything seems to work just fine. A pv is created:

  $ oc get pv | grep lars-test-pvc
  pvc-043ff7b2-9adb-497b-8204-4c8d5fc56c15   557Gi      RWO            Delete           Bound         default/lars-test-pvc   hostpath-provisioner            80s


And the pod runs as expected:

  $ oc get pod lars-test-pod
  NAME            READY   STATUS    RESTARTS   AGE
  lars-test-pod   1/1     Running   0          27s


If I delete the pod...

  $ oc delete pod lars-test-pod

...the pod is removed successfully, but the pv persists.  If I try to delete the pv:

  $ oc delete pv pvc-043ff7b2-9adb-497b-8204-4c8d5fc56c15

The command reports:

  persistentvolume "pvc-043ff7b2-9adb-497b-8204-4c8d5fc56c15" deleted

But the command never exits. At this point, the pv status is "Terminating":

  $ oc get pv | grep lars-test-pvc
  pvc-043ff7b2-9adb-497b-8204-4c8d5fc56c15   557Gi      RWO            Delete           Terminating   default/lars-test-pvc   hostpath-provisioner            2m35s

If we delete the claim itself...

  $ oc delete pvc lars-test-pvc

...this seems to correctly delete both the pvc and the pv. Should attempting to delete the pv succeed? If not, should the command return an error message instead of hanging?