Pluggable observers

[rustyrazorblade]

Project board link

From IRC:

ha ha, yeah been thinking about it. Still deciding. We might fork it and tweak some of the code to basically to hook custom listeners/callbacks on the success/failure cases. Basically trigger off a slack alert if the repair failed

It would be very cool if we shipped support for pluggable classes that can register as observers to handle things like failure, etc.

┆Issue is synchronized with this Jira Story by Unito
┆Issue Number: REAP-189

[zznate]

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

[adejanovski]

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 ?

[rustyrazorblade]

URL callbacks sound great. Better than what I had suggested. +1 from me
On Fri, Oct 28, 2016 at 3:32 AM Alexander Dejanovski <
notifications@github.com> 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
.

[rustyrazorblade]

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

[michaelsembwever]

👍

[Ritu-Thakur]

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

[rustyrazorblade]

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

[Ritu-Thakur]

@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 !

[rustyrazorblade]

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?

[Ritu-Thakur]

Sure, we can test it.

[richardchesse]

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.