Feature #1714

Asynchronous Delete

Added by Ricardo Duarte almost 8 years ago. Updated over 7 years ago.

Status:ClosedStart date:01/05/2013
Priority:NormalDue date:
Assignee:-% Done:

0%

Category:-
Target version:Release 4.0
Resolution:worksforme Pull request:

Description

Currently, all operations that result into something being deleted (ex.: a disk, a instance, etc) are committed imediatelly.
Because data is deleted, there is no (easy) way for users to revert the action.
It could be useful to do a "soft-delete" instead. Objects are flagged as deleted, but are only physically deleted after some time or at some time of day.

This would work as follows:
- User deletes an instance
- OpenNebula sets the "deleted" flag to true and "deleted_at" to timestamp on the image and the intance, but does not delete the image from the system ds. Images are disabled and instances are powered off.
- Every day, a background job iterates over all the "deleted=true" and deletes the images from the system DS that have current_time - deleted_at > deleted_keep_period
- During the "deleted_keep_period" the user can undelete the object. OpenNebula sets the "deleted" flag to false and enables all the objects and restarts all undeleted instances

As this required a database change, 4.0 would be a good target for this feature.


Related issues

Related to Feature #1483: Define VM deploy and shutdown times for the scheduler Closed 09/20/2012

History

#1 Updated by Ruben S. Montero almost 8 years ago

  • Target version deleted (Release 4.0)

#2 Updated by Ruben S. Montero over 7 years ago

  • Status changed from New to Closed
  • Target version set to Release 4.0
  • Resolution set to worksforme

There has been a couple of new features that address this:
1.- We now have a better delete synchronization so delete operations are safe
2.- we have scheduled actions so an user can actually schedule the deletion of a VM

The workfow would be:

1.- User schedule delete at a given time
2.- User poweroff the VM (disks are kept in the system ds)
3.- User can remove the delete operation and resume the VM any time before the action expires
4.- The system deletes the VM at the scheduled time if the operation was not removed

I think it pretty much cover your use case.

Also available in: Atom PDF