Feature #18481
closed
Added by Jason Dillaman over 7 years ago.
Updated about 7 years ago.
Description
Optionally support delaying an image's deletion for a configurable amount of time. This would involve renaming the image and listing it within a "pending deleted image" / recycle bin directory (to avoid throwing false EEXISTS errors if an image w/ the same name is recreated).
This technique could be used to permit the deletion of parent images that still have associated children until the last child is flattened or deleted. It would also be useful for rbd-mirror daemon to handle deletions of parent images where a non-replicated image is linked as a child.
- Assignee set to Ricardo Dias
Jason Dillaman wrote:
This technique could be used to permit the deletion of parent images that still have associated children until the last child is flattened or deleted. It would also be useful for rbd-mirror daemon to handle deletions of parent images where a non-replicated image is linked as a child.
In the description the objective of this feature is to delay the deletion for an "amount of time", but in the case you mention above it looks that what you want is to delay the deletion of the parent until the last child disappears.
Should we support both cases, either delay by an amount of time or delay until the last child is removed?
Also, regarding the rbd-mirror daemon I can understand the necessity of this new operation, but in which other scenario one would try to delete the parent image before deleting the child images?
Yes, both case. In regards to deleting the parent, it's actually a common thing that people have developed a lot of workarounds to support. In OpenStack, for example, an attempt to delete a glance image or cinder volume results in flattening and renaming of image and all sorts of other workarounds.
- Status changed from New to In Progress
- Status changed from In Progress to Resolved
Also available in: Atom
PDF