every week on average, we have a question about foreman_hooks, how they work, why things are missing in JSON, why a hook does not work or which ActiveRecord action should be used to do something.
Foreman hooks is a nice hack for developers or more experienced users. It assumes some knowledge around ActiveRecord in Ruby on Rails. We have passed the point when this is feasible, so many users are struggling with this.
I propose to drop foreman_hooks long-term and offer similar capability in Foreman core. We should not expose ActiveRecord internals to users. My initial idea is to identify the most important points where users want to hook scripts and hardcode them into our codebase under some readable names like host_added or host_deleted.
This gives us opportunity to either explicitly create those scripts using a rake task or on every start with some descriptive comments so users can simply edit them, or build GUI around this. If we want to go further, we could use our templating engine to build external scripts or even execute Ruby code via safe-mode. But I tend to prefer simple solutions in general.
I would like to identify where we need such an extension points in our codebase.
It seems like this would be yet another object change event subsystem. Other examples include audits and email notifications. Would it be possible/feasible to make these a single subsystem? Then, developers could add events onto a bus and some could be audited, some could results in emails, and come could result in external functions being called.
Both audit and notifications are good examples of resources to include in hooks-ng.
I am not sure about benefits of creating single event subsystem for audits, notifications or emails - every each one of these has some specifics, use different stacks (ActiveRecord vs Rails Mailer vs Custom notifications code).
But I like the idea of leaving hook execution on user - we could publish those events (including low-level ActiveRecord ones for those who are interested) on some generic bus - would be up to the user how they would consume these. Could be easier to debug and write those.
I was assuming 1 event system, with many consumers (notifications, emails, etc) which customers could add new consumers into. That seems to be the model which new architectures go to. Have an event bus that new consumers can tap into.
I think a (relatively) simple system that allows people to connect Foreman to other things we haven’t thought of yet (without the complexity of writing a plugin for it) is an important feature.
That doesn’t need to be AR based, event-driven stuff is fine too (webhooks anyone?). I’m also all for moving the most common stuff into core as clear extension points. Just don’t remove people’s ability to cross that “last mile” in their own deployments
Agree that a simple way to test hooks during development would be
beneficial. Perhaps just a blog on how to one goes about developing a hook
may be enough. For example, when I was working on the repository sync and
pre/post content view promote hooks, I hardcoded in sample data so that I
could execute the scripts directly to test.
As an admin, it would be nice to have a way to see (in settings?) which
hooks are present and be able to toggle them on/off.
If hooks are a utility widely used we (devs) should definitely bump up the
RFE priority.
