Hide Forgot
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 oc v3.9.14 kubernetes v1.9.1+a0ce1bc657 features: Basic-Auth GSSAPI Kerberos SPNEGO Server https://knakayam-ose39-all.example.com:8443 openshift v3.9.14 kubernetes v1.9.1+a0ce1bc657 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 persistentvolumeclaims/registry-claim 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 storageClassName: dynamic Actual results: - Please refer to step-3 above. It always has "storageClassName: dynamic" so that it cannot bind to static PV(pv0001). Expected results: - Assign PVC created by oc set volume bind to static PV. Additional info: - 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. https://access.redhat.com/errata/RHBA-2019:0758