Hide Forgot
Description of problem: StorageClass deletion should fail if claims are associated with it. ############ # oc get storageclass NAME TYPE fast kubernetes.io/glusterfs slow kubernetes.io/glusterfs # oc get pvc NAME STATUS VOLUME CAPACITY ACCESSMODES AGE claim1 Bound pvc-d2a7a45c-a0f4-11e6-b4fe-525400f911fc 12Gi RWO 5d claim2 Bound pvc-d62c36a3-a0f4-11e6-b4fe-525400f911fc 14Gi RWO 5d claim3 Bound pvc-a89b0d1f-a1a1-11e6-b4fe-525400f911fc 16Gi RWO 4d claim4 Bound pvc-6543651e-a1a2-11e6-b4fe-525400f911fc 18Gi RWO 4d # oc get pv NAME CAPACITY ACCESSMODES RECLAIMPOLICY STATUS CLAIM REASON AGE pvc-6543651e-a1a2-11e6-b4fe-525400f911fc 18Gi RWO Delete Bound storage-project/claim4 4d pvc-a89b0d1f-a1a1-11e6-b4fe-525400f911fc 16Gi RWO Delete Bound storage-project/claim3 4d pvc-d2a7a45c-a0f4-11e6-b4fe-525400f911fc 12Gi RWO Delete Bound storage-project/claim1 5d pvc-d62c36a3-a0f4-11e6-b4fe-525400f911fc 14Gi RWO Delete Bound storage-project/claim2 5d registry-volume 5Gi RWX Retain Bound default/registry-claim 12d # oc describe pvc claim3 Name: claim3 Namespace: storage-project StorageClass: fast Status: Bound Volume: pvc-a89b0d1f-a1a1-11e6-b4fe-525400f911fc Labels: <none> Capacity: 16Gi Access Modes: RWO No events. # oc delete storageclass fast storageclass "fast" deleted # oc get storageclass NAME TYPE slow kubernetes.io/glusterfs # oc get pv NAME CAPACITY ACCESSMODES RECLAIMPOLICY STATUS CLAIM REASON AGE pvc-a89b0d1f-a1a1-11e6-b4fe-525400f911fc 16Gi RWO Delete Bound storage-project/claim3 4d pvc-d2a7a45c-a0f4-11e6-b4fe-525400f911fc 12Gi RWO Delete Bound storage-project/claim1 5d pvc-d62c36a3-a0f4-11e6-b4fe-525400f911fc 14Gi RWO Delete Bound storage-project/claim2 5d registry-volume 5Gi RWX Retain Bound default/registry-claim 12d oc get pvc NAME STATUS VOLUME CAPACITY ACCESSMODES AGE claim1 Bound pvc-d2a7a45c-a0f4-11e6-b4fe-525400f911fc 12Gi RWO 5d claim2 Bound pvc-d62c36a3-a0f4-11e6-b4fe-525400f911fc 14Gi RWO 5d claim3 Bound pvc-a89b0d1f-a1a1-11e6-b4fe-525400f911fc 16Gi RWO 4d #############
The working mechanism of Storage class is common for all the provisioners. This is not something we can do it from plugin (ex: GlusterFS) side. This has to be taken care in the PV controller in kubernetes. I would like to call this as NOT A BUG. Please feel free to reopen if you think otherwise.
(In reply to Humble Chirammal from comment #2) > The working mechanism of Storage class is common for all the provisioners. > This is not something we can do it from plugin (ex: GlusterFS) side. This > has to be taken care in the PV controller in kubernetes. I would like to > call this as NOT A BUG. Please feel free to reopen if you think otherwise. I still feel that this should be fixed w.r.t CNS. If it's not possible for this release, we can keep this BZ open and track it for the next release.
(In reply to Prasanth from comment #3) > (In reply to Humble Chirammal from comment #2) > > The working mechanism of Storage class is common for all the provisioners. > > This is not something we can do it from plugin (ex: GlusterFS) side. This > > has to be taken care in the PV controller in kubernetes. I would like to > > call this as NOT A BUG. Please feel free to reopen if you think otherwise. > > I still feel that this should be fixed w.r.t CNS. If it's not possible for > this release, we can keep this BZ open and track it for the next release. Just to clarify, the storage class is designed this way and the plugin ( ex: Glusterfs/Ceph..etc) does not have any control to change it. I really doubt the upstream will accept this design request at all. Any way, what I can do here is, to trigger a discussion in upstream and get the feedback. However please note that, we/CNS does not have any control on this. To summarize, at present, this is working as expected or as per design. Also I dont know, whether we need to track it in CNS.
todo: trigger kubernetes upstream discussion. at earliers for 3.5.
Upstream Issue # https://github.com/kubernetes/kubernetes/issues/40728