Details
-
New Feature
-
Status: Open
-
Major
-
Resolution: Unresolved
-
None
-
None
-
None
Description
There is currently nothing in VCL which prevents image creators from creating any number of images and image revisions. There is also nothing which automatically flags revisions as deleted or automatically deletes images from storage. Flagging revisions as deleted is up to the image creator or another admin with sufficient privileges. This can be problematic, especially in environments where image creation privileges are delegated to many users. Over time, many revisions accumulate which will never be reserved again. Storage is wasted as a result.
It would be beneficial to have a method for image revisions expire when certain criteria are met. Once expired, revisions will automatically be flagged as deleted and can be purged from storage. Great care obviously needs to be taken.
Proposed design:
Add an imagerevision.expiredate field to the database. The type will be DATE and null values will be allowed. Null be the default value.
Add a new state to the database named something like expireimage. As part of the vcld daemon, a management node would occasionally start a process for this state. It would retrieve several parameters stored in the database which determine the criteria that determine which revisions would expire and when. It would then find the revisions meeting the criteria and set the imagerevision.expiredate field to a date in the future. The amount of time in the future will also be configurable.
The process would also check any revisions which previously had their expiredate set. The tunable parameters could have changed between the time when expiredate was set and when a subsequent expireimage process runs. It would check to make sure the revision still meets the criteria and that the date set is still appropriate.
Image owners would be notified periodically for revisions with an expiredate set before the date is reached. The vcld process will handle this and the frequency of the notifications will also be tunable.
For revisions which have an expiredate which has been reached, the process will set imagerevision.deleted to 1 and update imagerevision.datedeleted. It would not actually delete any image revisions from storage at this stage. This feature could be added in the future.
There obviously needs to be a way for image owners to prevent revisions from being automatically flagged as deleted if they want to keep the revision for whatever reason. The notifications would include instructions. Simply making a reservation for the revision could be one way to accomplish this. Whenever a user makes a reservation for a revision which has expiredate set, the frontend would always set expiredate back to null.
Forcing revision owners to make a reservation for every revision they want to keep could be a hassle for them. Another option could be to add a feature to the image properties page to show the expire dates for the revisions and a button to reset them.
The criteria which determine which images to expire and when would depend on:
- Whether or not the image revision is set to production
- The last time a reservation was made for the revision
- Whether or not a reservation was ever made for the revision
- Whether the production revision is newer or older than the revision being considered