Move Event Handlers to an out of process design.

[jonathannewell]

Comments from Event Var Handler pull-request.

As far as event handlers I was just thinking a rest api that allows a handler to register/unregister itself. So, basically, I (an event handler) call into Deployadactyl and say I am interested in xyz event. I provide Deploydactyl a URL where it will call me when that event occurs. The event api would be the same it just would occur via rest and allow the handlers to be out of process. This would prevent a handler from potentially abending Deploydactyl and allow handlers to be coded completely separately. If folks choose to contribute a repo could be setup to allow folks to contribute there handlers but it wouldn't be required. The only change I would suggest to the API would be something that allows handlers to specify a precedence when they register...not just FIFO.

One other consideration on handlers. Probably need specify by event what data will be provided to handlers or allow the handler to tell the event manager what data it needs to be provided when the event is published. I like the second options even though it is more complex. Just need to specify by even what data is available. Meaning, some events would have access to more data than others. The data piece is the only outlier in the out of process model.

[mattjcurry]

This sounds a lot like we webhook. Perhaps we should just implement it the same way that github webhooks are designed. I guess the question is if the handler needs to manipulate any data coming back into deployadactyl or not.

[jonathannewell]

I think you have hit upon a very salient issue. The event handler I just created does augment/manipulate data to some degree. It updates/re-writes the manifest of the app being deployed. So, it doesn't change data in the Deployadactyl process but comes close. Out of process plugins/extensions are very typical in Go. I wonder if there are some established patterns/practices out there we could look at?

[trayo]

It possible to write a webhooks event handler that broadcasts on each event. We wrote the event handler in a way that if you have an important event that you need to run before a deployment and ensure works, you send an error back to the event caller.

We're thinking of writing an event manager that broadcasts http calls to whoever is listening for requests. Then you can write a microservice that listens to the request and runs whatever operations asynchronously as long as it throws back a 200 right away.