Description of problem:
- When cluster has default storageclass, PVC created by oc set volume always bind to the default storage class. In ohter words, it cannot be bound to static PV.
Version-Release number of selected component (if applicable):
- OCP 3.9
# oc version
features: Basic-Auth GSSAPI Kerberos SPNEGO
How reproducible: 100%
Steps to Reproduce:
1. Prepare default StorageClass (dynamic in below) and staic PV(pv0001)
# oc get sc
NAME PROVISIONER AGE
cephfs ceph.com/cephfs 44d
dynamic (default) kubernetes.io/rbd 48d
// Also, we prepare for static PV. (We would like to let PVC bind to this static PV.)
# oc get pv
NAME CAPACITY ACCESS MODES RECLAIM POLICY STATUS CLAIM STORAGECLASS REASON AGE
pv0001 1Gi RWX Recycle Available default/claim1 23s
2. Run oc set volumes without --claim-name.
# oc set volumes dc/docker-registry --name=registry-storage --claim-name=registry-claim --claim-mode=ReadWriteMany --claim-size=1Gi --add
3. PVC created is alywas has "storageClassName: dynamic".
# oc get pvc
NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE
registry-claim Pending dynamic 1m
# oc get pvc registry-claim -o yaml |grep storageClassName
- Please refer to step-3 above. It always has "storageClassName: dynamic" so that it cannot bind to static PV(pv0001).
- Assign PVC created by oc set volume bind to static PV.
- If we can specify 'storageClassName: ""', then it is possible to use staic PV - ref: https://kubernetes.io/docs/concepts/storage/persistent-volumes/#class-1
Proposal patch https://github.com/openshift/origin/pull/20889
Verified in v4.0.0-0.79.0. Give default sc and static pv exist, pvc is bound to the latter via --claim-class="".
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.
For information on the advisory, and where to find the updated
files, follow the link below.
If the solution does not work for you, open a new bug report.