Skip to content
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

Closed
benbz opened this issue Aug 26, 2022 · 3 comments
Closed

Rageshake should support defining a retention period #59

benbz opened this issue Aug 26, 2022 · 3 comments

Comments

@benbz
Copy link

benbz commented Aug 26, 2022

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

@michaelkaye
Copy link
Contributor

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...

@michaelkaye
Copy link
Contributor

michaelkaye commented Sep 7, 2022

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 grep on a filesystem would be great for (vs the object storage in #60).

(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)

@michaelkaye
Copy link
Contributor

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).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants