]> git.apps.os.sepia.ceph.com Git - ceph-ci.git/commit
librbd: disallow "rbd trash mv" if image is in a group
authorIlya Dryomov <idryomov@gmail.com>
Wed, 16 Apr 2025 11:15:19 +0000 (13:15 +0200)
committerIlya Dryomov <idryomov@gmail.com>
Fri, 25 Apr 2025 07:33:43 +0000 (09:33 +0200)
commit8d740b1119ab9459bdceb8c84305782f8dd1f06d
tree21435a5fa5b61479151e0b4b9e569713ef10667c
parente924d34e154388a0341e668b6e83e2f0f550ecf6
librbd: disallow "rbd trash mv" if image is in a group

Removing an image that is a member of a group has always been
disallowed.  However, moving an image that is a member of a group to
trash is currently allowed and this is deceptive -- the only reason for
a user to move an image to trash should be the intent to remove it.

More importantly, group APIs operate in terms of image names -- there
are no corresponding variants that would operate in terms of image IDs.
For example, even though internally GroupImageSpec struct stores an
image ID, the public rbd_group_image_info_t struct insists on an image
name.  When rbd_group_image_list() encounters a trashed member image
(i.e. one that doesn't have a name), it just fails with ENOENT and no
listing gets produced at all until the offending image is restored from
trash.  Something like this can be very hard to debug for an average
user, so let's make rbd_trash_move() fail with EMLINK the same way as
rbd_remove() does in this scenario.

The one case where moving a member image to trash makes sense is live
migration where the source image gets trashed to be almost immediately
replaced by the destination image as part of preparing migration.

Fixes: https://tracker.ceph.com/issues/71026
Signed-off-by: Ilya Dryomov <idryomov@gmail.com>
(cherry picked from commit 2ae4a57e160f21201b9dfb4c8adb02f2826c7106)

Conflicts:
PendingReleaseNotes [ moved to >=18.2.7 section ]
PendingReleaseNotes
src/librbd/api/Trash.cc
src/test/pybind/test_rbd.py
src/tools/rbd/action/Trash.cc