Rageshake support for object storage

[benbz]

Is your feature request related to a problem? Please describe.
Rageshake can take an unbounded amount of storage space. Object storage is generally more elastic than using local disk.

Describe the solution you'd like
Rageshake supports storing rageshakes in object storage (S3-compatible API preferably) rather than local disk so that administrators of Rageshake do not need to worry about disk usage

Describe alternatives you've considered
Similar to #59, Rageshake could support a maximum total size of stored rageshakes and delete the oldest rageshakes until under the desired maximum store size.

Additional context
n/a

[gaelgatelement]

@michaelkaye : Any opinion on this issue + issue #59 ? It might become important soon enough, corus disk consumption is increasing faster and faster.

[michaelkaye]

Object storage has the big downside that grep isn't efficient on it.

The search engine we have only indexes a few weeks at most because of the cost requirements to keep that going - if we remove the option to grep then we would need to replace with ... a lot of money for indexing servers.

[benbz]

OOI is grep a normal use-case? I'm mostly familiar with people using the links through from the issues

[michaelkaye]

It depends what we're doing with the rageshakes:

Given an issue looking at the problem is a common use, but the inverse is also used - given a problem, find other logs like it.
The rageshake-searcher was a good start on that, but it doesn't really (economincally) scale to years of logs vs just "grep".
Unfortunately it is a low-frequency operation, but if we want to and have moved to object storage it becomes impossible without additional indexing.

(that and it'd be a chunk of work to change it)