during the next sprint, I would like to extend the initial idea and implementation of Foreman core subscription API and @TimoGoebel 's foreman_webhooks plugin. We think it is the best and most flexible way of preaparing Foreman for the future in regard to integration.
The initial idea and motivation remains the same - we will maintain a simple subscription API in Foreman core and allow plugins to hook on various events similarly to the existing foreman_hooks plugin. Although I planned developing some other plugins (I mentioned Redis pub/sub), for the best user experience we would like to go forward with foreman_webhooks as the defacto implementation. For more details about the process how we got here, read:
Timo and our friends at iRonin layed the basics: we have subscription API in Foreman core and there’s the WIP prototype published at:
It provides a simple interface to create webhooks, define URL and actions on which they should trigger. It integrates with the subscription API to hook on these events and it processes them by creating ActiveJobs to deliver them to external services.
We would like to expand on that:
- Add new template kind “webhook” defining payloads in a flexible way.
- Set of new macros which allows loading basic records via a database ID (couple of these already exist).
- Integrate template payload to the hook definitions.
- Rewrite UI in React.
- Deliver API and CLI portions of the same.
- Prepare some example payload templates for selected external services.
- Create a smart proxy module webhook “shell” endpoint and payload template for easy testing and upgrade path for foreman_hooks users (executes a shell script).
We will not be aiming for 100% compatibility with current foreman_hooks, the plugin is not going anywhere and can be used alongside with foreman_webhooks going forward. We expect to ship it “until it breaks”, at least for few major releases so there is enough transition time for all users.
I’d like to ask @TimoGoebel if he is willing to contribute his WIP as a starting point for this work. It looks like 90% of the WIP code can be directly used for what we are planning to build.
Edit: I’ve described the minimum viable product, we would like to deliver other features like:
- Audit support and extensive logging.
- Request-session tracking via HTTP headers.
- Add configurable timeout
- Add re-triggering support and perhaps configurable amount of retries
- Flag which can enable or disable hooks per hook item
- Configurable HTTP headers (e.g. for secret tokens)
Take this as a TODO list which I will keep up to date as we dig deeper.