Description of problem: Create a claim requesting dynamically provisioned storage, when the PV is created, it's bound to the PVC, but when getting PVC status, it was 'Pending'. It lasted about 6~7 minutes until PV and PVC status are consistent. Version-Release number of selected component (if applicable): openshift v3.1.1.0 kubernetes v1.1.0-origin-1107-g4c8e6f4 etcd 2.1.2 How reproducible: Always Steps to Reproduce: 1. Create a Persistent Volume Claim requesting dynamically provisioned storage: { "kind": "PersistentVolumeClaim", "apiVersion": "v1", "metadata": { "name": "cinderc", "annotations": { "volume.alpha.kubernetes.io/storage-class": "foo" } }, "spec": { "accessModes": [ "ReadWriteOnce" ], "resources": { "requests": { "storage": "3Gi" } } } } 2. oc get pv 3. oc get pvc Actual results: After step 2: NAME LABELS CAPACITY ACCESSMODES STATUS CLAIM REASON AGE pv-cinder-cg4qe <none> 3Gi RWO Bound jhou/cinderc 4m After step 3: NAME LABELS STATUS VOLUME CAPACITY ACCESSMODES AGE cinderc <none> Pending 5m Expected results: After step 3, should also see pvc status as 'Bound'. Their status should be consistent. Additional info:
The PVC's status will eventually become 'Bound', it's just that the first 6~7 minutes, PVC is always shown as 'Pending', so this bug is in low severity.
This bug is tracked upstream as https://github.com/kubernetes/kubernetes/issues/18830 and it has been fixed by this Kubernetes PR: https://github.com/kubernetes/kubernetes/pull/18877. We need to push this PR also to OpenShift.
We're waiting for next OpenShift rebase of Kubernetes, please re-test when it happens.
Verified with openshift v1.1.2-260-gf556adc kubernetes v1.2.0-origin etcd 2.2.2+git Now the PV and PVC status are consistent after PV is dynamically provisioned. The issue is fixed.
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/RHSA-2016:1064