Description of problem: When volume.beta.kubernetes.io/storage-class is set on PVCs with Local Storage Operator, the PVCs remain pending. If instead .spec.storageClassName attribute is set, the PVCs get bound. Version-Release number of selected component (if applicable): oc version Client Version: openshift-clients-4.2.2-201910250432 Server Version: 4.2.10 Kubernetes Version: v1.14.6+17b1cc6 How reproducible: ALWAYS Steps to Reproduce: 1. Deploy OCP 4.2 with Local Storage Operator 2. Instantiate Local Volume, e.g.: https://gist.github.com/miminar/0a8e57323b00caaf488af1c03bb9fea8#file-localvolume-yaml 3. Wait for PVs to be created 4. Instantiate PVC with volume.beta.kubernetes.io/storage-class annotation instead of .spec.storageClassName attribute pointing to the newly created Storage Class. For example using statefulset like this one: https://gist.github.com/miminar/0a8e57323b00caaf488af1c03bb9fea8#file-scann-bug-yaml Actual results: The resulting PVC remains Pending Expected results: The PVC gets Bound PV Dump: https://gist.github.com/miminar/0a8e57323b00caaf488af1c03bb9fea8#file-local-pv-7b884bb4-yaml PVC Dump: https://gist.github.com/miminar/0a8e57323b00caaf488af1c03bb9fea8#file-oc-get-pvc-out-yaml StorageClass Dump (if StorageClass used by PV/PVC): https://gist.github.com/miminar/0a8e57323b00caaf488af1c03bb9fea8#file-local-sc-yaml Additional info: If the volume.beta.kubernetes.io/storage-class annotation in PVC is replaced with .spec.storageClassName, the PVC gets Bound.
This bug has been fixed in OCP 4.3 and we do not backport "medium" severity fixes.