Red Hat Bugzilla – Bug 1279344
Inconsistent PV and PVC bound displayed
Last modified: 2016-05-12 12:25:17 EDT
Description of problem:
Delete and create a new PVC with same name before the bound PV is released, the PVC is always shown bound to the PV even if it is not.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Create 2 PVs with accessMode RWX and RWO respectively
oc create -f https://raw.githubusercontent.com/openshift-qe/v3-testfiles/master/persistent-volumes/nfs/nfs-default-rwx.json
oc create -f https://raw.githubusercontent.com/openshift-qe/v3-testfiles/master/persistent-volumes/nfs/nfs-recycle-rwo.json
2. Create a PVC with accessMode RWX
oc create -f https://raw.githubusercontent.com/openshift-qe/v3-testfiles/master/persistent-volumes/nfs/claim-rwx.json
3. After the PVC is bound, delete it, immediately before the PV is released, create another PVC with accessMode RWO, the PVC should have same name with the deleted PVC
oc delete pvc nfsc
oc create -f https://raw.githubusercontent.com/openshift-qe/v3-testfiles/master/persistent-volumes/nfs/claim-rwo.json
4. List all PVs: 'oc get pv'
5. List PVC: 'oc get pvc'
After step 4:
The 'oc get pv' shows that 1 PVC bound to 2 different PVs
NAME LABELS CAPACITY ACCESSMODES STATUS CLAIM REASON AGE
nfs <none> 5Gi RWX Bound jhou/nfsc 13m
nfsj <none> 5Gi RWO Bound jhou/nfsc 13m
After step 5:
The PVC is bound to the PV that is RWO
NAME LABELS STATUS VOLUME CAPACITY ACCESSMODES AGE
nfsc <none> Bound nfsj 5Gi RWO 12m
The PV with accessMode RWX should be in released/available status depending on it's reclaim policy, it should not be shown as 'Bound' to the deleted PVC.
The bug here is the controller looking at the claim namespace and name when comparing what a volume is bound to. The 2nd claim used in the example above has the same name/namespace, so the volume sees the existing claim and thinks it is still bound.
The solution is to compare object UIDs instead of namespace/name.
Bug fix is upstream: https://github.com/kubernetes/kubernetes/pull/20197
I verified #20197 is in Origin after the most recent rebase.
The issue is not reproducible, the bug 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.