Removing a clone that fails to open its parent might leave dangling rbd_children reference
Create a parent image in pool X, and a clone in pool Y. Using a user that doesn't have any permission to pool X, remove the clone image:
# rbd --id test -p rbd rm destination 2016-12-21 11:50:03.758221 7f32b7459700 -1 librbd::image::OpenRequest: failed to retreive name: (1) Operation not permitted 2016-12-21 11:50:03.758288 7f32b6c58700 -1 librbd::image::RefreshParentRequest: failed to open parent image: (1) Operation not permitted 2016-12-21 11:50:03.758312 7f32b6c58700 -1 librbd::image::RefreshRequest: failed to refresh parent image: (1) Operation not permitted 2016-12-21 11:50:03.758333 7f32b6c58700 -1 librbd::image::OpenRequest: failed to refresh image: (1) Operation not permitted 2016-12-21 11:50:03.759366 7f32b6c58700 -1 librbd::ImageState: failed to open image: (1) Operation not permitted Removing image: 100% complete...done.
Now the clone image has been removed, but the parent image cannot be deleted because there is a dangling reference to the deleted clone image.
#2 Updated by Jason Dillaman about 2 years ago
(1) if the parent image fails to be opened, we still want to ensure the child image is "opened" so that it can properly clean up. Right now failing to open the parent will cause the remove logic to assume the child image has already been deleted so it just removes the image from the directory. In the remove case, we could pass a special op to OpenRequest to say "don't attempt to open the parent".
(2) even if the parent fails to open, if we have a parent spec, we should ensure we update rbd_children to remove our reference.