Bug 1962956
| Summary: | [Tracker for OCP BZ #1990428] [RBD][Thick] Deleting the PVC and RBD provisioner leader pod while thick provisioning is progressing, will leave a stale image | ||
|---|---|---|---|
| Product: | [Red Hat Storage] Red Hat OpenShift Data Foundation | Reporter: | Jilju Joy <jijoy> |
| Component: | distribution | Assignee: | Eran Tamir <etamir> |
| Status: | CLOSED DEFERRED | QA Contact: | Elad <ebenahar> |
| Severity: | high | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 4.8 | CC: | aeyal, alitke, bniver, madam, mrajanna, muagarwa, nberry, ndevos, ocs-bugs, odf-bz-bot, rcyriac, sostapov, ykaul |
| Target Milestone: | --- | Keywords: | Automation, Tracking |
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Known Issue | |
| Doc Text: |
.Deleting the pending PVC and RBD provisioner leader pod while the thick provisioning is progressing, will leave a stale image and OMAP metadata
When an RBD PVC is being thick provisioned, the Persistent Volume Claim (PVC) is in a `Pending` state. If the RBD provisioner leader and the PVC itself are deleted, the RBD image and OMAP metadata will not be deleted.
To address this issue, do not delete the PVC while the thick provisioning is in progress.
|
Story Points: | --- |
| Clone Of: | Environment: | ||
| Last Closed: | 2022-01-31 17:19:51 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Bug Depends On: | 1990428 | ||
| Bug Blocks: | 1966894 | ||
|
Description
Jilju Joy
2021-05-20 20:42:51 UTC
Jilju, this should happen without thick provisioning also (though the window is very small) Is it possible to verify? (In reply to Mudit Agarwal from comment #3) > Jilju, this should happen without thick provisioning also (though the window > is very small) > Is it possible to verify? Hi Mudit, I tried to test this multiple times. The provisioning was very quick. I0527 13:02:45.222042 1 controller.go:1335] provision "default/pvc-test-2" class "ocs-storagecluster-ceph-rbd": started I0527 13:02:45.275805 1 controller.go:1442] provision "default/pvc-test-2" class "ocs-storagecluster-ceph-rbd": volume "pvc-a83265d5-3cb7-48b4-a698-f56a79a56d7c" provisioned I0527 13:02:45.275823 1 controller.go:1459] provision "default/pvc-test-2" class "ocs-storagecluster-ceph-rbd": succeeded So I was not able to delete the PVC before the provisioning completed. Tested in version: ocs-operator.v4.8.0-399.ci As mentioned by Madhu in https://bugzilla.redhat.com/show_bug.cgi?id=1962956#c2, this is not something which can be handled by ceph-csi driver. This is an existing issue which can be seen more with thick provisioning. Moving it out for now, we need to raise a bug with OCP and see if we can fix it. The problem arises only when both the provisioner and the pending PVC is deleted. PVC can be deleted while thick provisioning is going on. But the suggested workaround gives an impression that a thick PVC cannot be deleted while provisioning is going on. It is true that we do not expect the user to check whether the provisioner was respinned before trying to delete a Pending PVC. The actual information we want to convey is "Do not delete a Pending RBD thick PVC if the active RBD provisioner pod was restarted after the start of PVC creation" The above statement can be rephrased, but this is the actual situation which can leave a stale image. I see Jilju responded. Clearing needinfo on me. In comment #5, Mudit states that a bug needs to be created against OCP to get a resolution to this issue. Has that happened? (In reply to Adam Litke from comment #13) > In comment #5, Mudit states that a bug needs to be created against OCP to > get a resolution to this issue. Has that happened? Not yet, Mudit is going to take care of that (today?). This is not something ceph-csi can address. This is a tracker for the OCP distribution that ODF builds upon, changing components accordingly. |