-
Notifications
You must be signed in to change notification settings - Fork 12
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Rageshake should support defining a retention period #59
Comments
External cronjobs will be safe for rageshake; all you'd end up with are broken links. The files are stored on disk in folders with a timestamp, so can be easily identified and removed by age. TBH, a cronjob is probably the right option here... |
Additionally, we probably want to search for all items that have certain properties recorded in their details.log.gz, for example the application or the version of the code - i can imagine that unreleased code rageshakes have a lower value over time compared to released code, and the autogenerated rageshakes might be less valuable than end user submitted ones (with human details) - this is probably a infrequent cross-item search use-case that (and yes, we could additionally implement a database to store the contents of the details.log.gz and be able to search that for objects to remove instead) |
So while rageshakes itself doesn't provide a retention period; the provided script can easily run as a cronjob to clean up behind the rageshakes server (as we only write in day-by-day folders). |
Is your feature request related to a problem? Please describe.
For the purpose of not holding onto data longer than needed (are Rageshakes older than 1 year still going to contain useful and actionable information?) and for storage management reasons, Rageshake should cleanup rageshakes older than a configurable period of time
Describe the solution you'd like
A configuration option in Rageshake defining a retention period and Rageshake having a process to safely remove rageshakes outside of this retention period
Describe alternatives you've considered
A cronjob that does this outside of Rageshake. Without knowing more about Rageshake's internals I can't say whether or not this is safe. Regardless all deployments of Rageshake could benefit from the retention period so doing it in Rageshake gives it to all deployments with minimal extra work
Additional context
n/a
The text was updated successfully, but these errors were encountered: