rbd: do not return an error when deleting a non-existing image

[nixpanic]

Deleting an image that has been already remove, should not be reported
as a failure. This improves the idempotency of the rbdImage.Delete()
function, making it easier for callers to detect real errors.

Related issues

Found while working on #4502.

---

Show available bot commands

These commands are normally not required, but in case of issues, leave any of
the following bot commands in an otherwise empty comment in this PR:

• /retest ci/centos/<job-name>: retest the <job-name> after unrelated
  failure (please report the failure too!)

[Rakshith-R]

We need to not have this check in order to trigger

ceph-csi/internal/rbd/rbd_util.go

Line 623 in 611e5d9

func (ri *rbdImage) ensureImageCleanup(ctx context.Context) error {

[nixpanic]

We need to not have this check in order to trigger

ceph-csi/internal/rbd/rbd_util.go

Line 623 in 611e5d9

func (ri *rbdImage) ensureImageCleanup(ctx context.Context) error {

Sorry, I am not sure what you mean by that... ensureImageCleanup can cause a panic without those error checks?

[Madhu-1]

@nixpanic is AddTrashRemove Mrg API is also support this error message?

[nixpanic]

yes, it seemed so. I have been testing with the Ceph main branch, maybe things changed there?

[Rakshith-R]

We need to not have this check in order to trigger

ceph-csi/internal/rbd/rbd_util.go

Line 623 in 611e5d9

func (ri *rbdImage) ensureImageCleanup(ctx context.Context) error {

Sorry, I am not sure what you mean by that... ensureImageCleanup can cause a panic without those error checks?

If the image does not exist, then the flow should not have reached that point at all.
Image not being found would've lead to ensureImageCleanup in actual delete procedure.
I think there are multiple processes acting on same image that's causing this error/panic in your case ??

[nixpanic]

We need to not have this check in order to trigger

ceph-csi/internal/rbd/rbd_util.go

Line 623 in 611e5d9

func (ri *rbdImage) ensureImageCleanup(ctx context.Context) error {

Sorry, I am not sure what you mean by that... ensureImageCleanup can cause a panic without those error checks?

If the image does not exist, then the flow should not have reached that point at all. Image not being found would've lead to ensureImageCleanup in actual delete procedure. I think there are multiple processes acting on same image that's causing this error/panic in your case ??

I don't think it multiple processes are trying to delete the same volume at the same time. However a 2nd DeleteVolume seems to come immediately after the 1st completed (kubernetes-csi/external-provisioner#1235 might be related?).

[Madhu-1]

We need to not have this check in order to trigger

ceph-csi/internal/rbd/rbd_util.go

Line 623 in 611e5d9

func (ri *rbdImage) ensureImageCleanup(ctx context.Context) error {

Sorry, I am not sure what you mean by that... ensureImageCleanup can cause a panic without those error checks?

If the image does not exist, then the flow should not have reached that point at all. Image not being found would've lead to ensureImageCleanup in actual delete procedure. I think there are multiple processes acting on same image that's causing this error/panic in your case ??

I don't think it multiple processes are trying to delete the same volume at the same time. However a 2nd DeleteVolume seems to come immediately after the 1st completed (kubernetes-csi/external-provisioner#1235 might be related?).

we do have in memory lock to ensure that this should not happen.

@Rakshith-R any further comments on this one?

[Rakshith-R]

We need to not have this check in order to trigger

ceph-csi/internal/rbd/rbd_util.go

Line 623 in 611e5d9

func (ri *rbdImage) ensureImageCleanup(ctx context.Context) error {

Sorry, I am not sure what you mean by that... ensureImageCleanup can cause a panic without those error checks?

If the image does not exist, then the flow should not have reached that point at all. Image not being found would've lead to ensureImageCleanup in actual delete procedure. I think there are multiple processes acting on same image that's causing this error/panic in your case ??

I don't think it multiple processes are trying to delete the same volume at the same time. However a 2nd DeleteVolume seems to come immediately after the 1st completed (kubernetes-csi/external-provisioner#1235 might be related?).

we do have in memory lock to ensure that this should not happen.

@Rakshith-R any further comments on this one?

Yea, I think We'll encounter this error only when another process puts the image to trash while this process reaches the rbd.Trash(0) or ra.addTrashRemove call. The only reason a process gets to that stage is when a rbd image is found.

We should treat such occurrences as a race condition happening somewhere in the code and fix that instead of the current error check to avoid it.

(sorry, missed this comment earlier)

[Rakshith-R]

@nixpanic I think we can close this pr ?