search

theforeman / foreman_hooks

Run custom hook scripts on Foreman events
http://m0dlx.com/blog/Extending_Foreman_quickly_with_hook_scripts.html
GNU General Public License v3.0
56 stars 50 forks source link

question about events and hooks #21

Open logicminds opened 9 years ago

logicminds commented 9 years ago

First of all this plugin rocks!

I created a hook to kick off a puppet run via shelling out to mcollective whenever an update occurs. But now I want filter out some of the updates so that mco is not called every single time. For example:.

run mco command when a host group is updated. do not run mco command when other details are updated.

Since I am not able to compare any state information with the data coming in is there a way that I can see which call was made to trigger the hook? Specifically the url in the PUT statement

For example If my hook knew that update was called via /api/hosts/72/parameters/9 than I could exclude it from running the mco command.

Any way to pass the url as a new argument? PUT "/api/hosts/72/parameters/9"

domcleal commented 9 years ago

Hm, I don't know how easy that is to access where the hooks are received. It might require something cludgy like looking at the stack...

I'm beginning to get to the point where I'd like to pass more data in, get more data back out and make hooks more configurable. Would it be useful to get one larger piece of JSON on stdin with context information, or just keeping adding command line arguments?

XMol commented 3 years ago

Hello @domcleal,

I was researching on whether we could make our hook scripts more specific and found this issue.

At present, we have a hook to be executed on host/managed/after_update, but we only want to act when either the host's name or group was changed. Not when for example a new Puppet report is added or the value of some facts are updated, which happens every 30 minutes and fires the event in both cases. The only way we've found so far to determine what actually was updated when the script was triggered is to fetch the (complete) host information from Foreman (which reflects the state of the host before the hook finishes) and compare it to what is given as hook object JSON.

Would it be useful to get one larger piece of JSON on stdin with context information, or just keeping adding command line arguments?

In my humble opinion, that depends on the complexity of the information you want to give. Can you compress the context information into single, small words, then a command line argument is sufficient. Otherwise, extending the hook object JSON is more appropriate. Either way, it should not matter much for the script developers.