while this is definitely an option, I would like to disencourage from this low-level approach which did not pay off in the official foreman_hooks plugin. Users are hitting issues every time we changed our model, also not everything is an ActiveRecord event.
We are currently working hard on the new Subscription API which allows plugins to hook into Foreman events in a similar but more controlled manner. For end users, I would encourage users to consider using the new Foreman Webhooks plugin based on this API:
It makes use of our templating engine so everytime we change some internal data structure, webhooks should not break when using our own templates (or should be pretty easy to fix template clones by comparing the changes).
This all is work in progress but this is our priority now to deliver this in 2.3/2.4 timeframe. Feedback or contributions welcome!
Edit: After reading my post, I think the tone was not the best. To clarify, it’s awesome you share your work and we want to see as many plugins as possible. Thanks!
We know hooking in all events is not optimal; our use case would be to hook in models of interest instead, and to filter what is broadcasted. This is only an example on how to create ActionCable channels and broadcast data in the context of a Foreman plugin.
Edit: and the tone was OK, we’re here to build robust things and constructive notes are always good to read.
I think, that given we already have React/Redux in foreman, we should leverage it and go through redux actions instead of implementing native vanilla client.
Currently it was blocked as we were not 100% sure we are able to stick with Puma, as current stable release (2.1) is the first release containing it. So we didn’t want to depend on it heavily yet, but it should happen in next release cycle and end up in 2.4 if it goes well contributions and any help is definitelly welcome !