Please let me know if you have any comments. If there is no objection, I'll implement this feature.

tagging @Madhu-1 @travisn @Rakshith-R

Back from PTO and still catching up with things for now A side effect of doing this increases the storage consumption and breaks the chain of images.

Get the volumeHandle file of the PV
Get the name of the target RBD image from the volumeHandle field

RBD Image name and pool name might already be part of volumeAttributes we don't need to decode the volumeHandle

A side effect of doing this increases the storage consumption

In my opinion, it would not be a big problem because admins explicitly flatten their image rather than implicitly being done by ceph-csi or Rook.

However, as I described in the discussion in ceph-csi, parent PVC's data will remain in the temporary rbd image after deleting the parent rbd image. This limitation should be documented, or the temporary rbd image should be removed on flattening.

and breaks the chain of images.

Do you have any concern about braking the chain? If I recall correctly, rbd image still remember its parent image after flattening.

RBD Image name and pool name might already be part of volumeAttributes we don't need to decode the volumeHandle

Indeed, thanks.

A side effect of doing this increases the storage consumption

In my opinion, it would not be a big problem because admins explicitly flatten their image rather than implicitly being done by ceph-csi or Rook.

However, as I described in the discussion in ceph-csi, parent PVC's data will remain in the temporary rbd image after deleting the parent rbd image. This limitation should be documented, or the temporary rbd image should be removed on flattening.

the cleanup/steps to cleanup of the temporary image need to be handled properly as required.

and breaks the chain of images.

Do you have any concern about braking the chain? If I recall correctly, rbd image still remember its parent image after flattening.

Nothing we should be good

RBD Image name and pool name might already be part of volumeAttributes we don't need to decode the volumeHandle

Indeed, thanks.

However, as I described in the discussion in ceph-csi, parent PVC's data will remain in the temporary rbd image after deleting the parent rbd image. This limitation should be documented, or the temporary rbd image should be removed on flattening.
the cleanup/steps to cleanup of the temporary image need to be handled properly as required.

Thank you for your reply.

One more question. It is OK to delete the temporary image from kubectl rook-ceph when flattening PVC-PVC clone image? Or should it be done by other ways? If I understand correctly, the temporary image is specific to the cloned PVC in PVC-PVC clone and is safe to be deleted here.

However, as I described in the discussion in ceph-csi, parent PVC's data will remain in the temporary rbd image after deleting the parent rbd image. This limitation should be documented, or the temporary rbd image should be removed on flattening.
the cleanup/steps to cleanup of the temporary image need to be handled properly as required.

Thank you for your reply.

One more question. It is OK to delete the temporary image from kubectl rook-ceph when flattening PVC-PVC clone image? Or should it be done by other ways? If I understand correctly, the temporary image is specific to the cloned PVC in PVC-PVC clone and is safe to be deleted here.

@satoru-takeuchi it should be safe to delete it as it will not be used anymore. we introduced temporary image to avoid i/o performance issue when accessing the image mounted to the PVC because we never flattened the mapped image, we always wanted to flatten the temporary image. In this case as we are trying to flatten the actual rbd image we are move the temporary image to trash and add a task to remove it from trash.

@Madhu-1 Thank you very much! I'll implement this feature with considering the result of this discussion.

we introduced temporary image to avoid i/o performance issue when accessing the image mounted to the PVC because we never flattened the mapped image, we always wanted to flatten the temporary image.

I finally understood why temporary image exists, haha.