Andy Kurth created VCL-926:
------------------------------
Summary: Image revision expiration
Key: VCL-926
URL: https://issues.apache.org/jira/browse/VCL-926
Project: VCL
Issue Type: New Feature
Components: database, vcld (backend), web gui (frontend)
Reporter: Andy Kurth
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
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
