Pluggable observers about cassandra-reaper HOT 11 OPEN

+1 on that. Fantastic idea. @adejanovski what do you think the scope of something like this might be?

from cassandra-reaper.

That would be nice indeed.
The way I see it, we could trigger calling a url through HTTP on different events (repair started, failed, finished) to have generic push of events. Callbacks should be registered through the UI and stored in the database.

Having observers through pluggable classes would require users to recompile Reaper which we might not want.

Another way to make it very generic would be to allow people to write Groovy scripts to register callbacks.

And of course we can maintain a set of specific triggers in the Reaper codebase to ease integration with Slack, etc...

@rustyrazorblade @zznate : thoughts ?

from cassandra-reaper.

URL callbacks sound great. Better than what I had suggested. +1 from me
On Fri, Oct 28, 2016 at 3:32 AM Alexander Dejanovski <
[email protected]> wrote:

That would be nice indeed.
The way I see it, we could trigger calling a url through HTTP on different
events (repair started, failed, finished) to have generic push of events.
Callbacks should be registered through the UI and stored in the database.

Having observers through pluggable classes would require users to
recompile Reaper which we might not want.

Another way to make it very generic would be to allow people to write
Groovy scripts to register callbacks.

And of course we can maintain a set of specific triggers in the Reaper
codebase to ease integration with Slack, etc...

@rustyrazorblade https://github.com/rustyrazorblade @zznate
https://github.com/zznate : thoughts ?

—
You are receiving this because you were mentioned.

Reply to this email directly, view it on GitHub
#11 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAUn0A3ZUWhz1VY4O0aNN_LuIy3BuotUks5q4c8_gaJpZM4KgPGm
.

from cassandra-reaper.

How about we design an interface for event handling and do an implementation as HTTP callbacks? It solves most people's needs but also give an escape hatch for folks that want something really simple, like an email when things fail. See #79

from cassandra-reaper.

👍

from cassandra-reaper.

@michaelsembwever
Is this email feature already developed in some other branch or is it in pipeline?

from cassandra-reaper.

It's only been discussed here. Are you interested in working on it @ritu0407 ?

from cassandra-reaper.

@rustyrazorblade
This is our first attempt to use reaper in the project. Right now we don't have any plans to enhance the tool and as long as we have a way to check the logs to know if it's working or not, that's good enough.
Thanks for developing this tool !

from cassandra-reaper.

When we start working on it, we'll update this issue and the work will be in a branch here. Would you be able to help us test it and give feedback along its development?

from cassandra-reaper.

Sure, we can test it.

from cassandra-reaper.

I think the implementation here has overshadowed the importance of the actual feature. Having configuration options for simple shell scripts for start, end, failure of repair runs is important for a set-it-and-forget-it tool like this (what a former colleague calls the "Ronco toolsuite"). Reaper runs generally once a week for most orgs and works well. Until one week you have a repair that doesn't finish for some reason and then it runs for 21 days straight or is erroring out silently because no one looks at it. Simple shell script hooks would go a long way here. People can hook into whatever notification systems they want from there.

from cassandra-reaper.