https://issues.rudder.io/https://issues.rudder.io/themes/rudder7/favicon/favicon.ico?17096450182016-05-20T14:27:41ZIssue TrackerRudder - User story #8353: Implement notifications for different server-side actions and events (hooks)https://issues.rudder.io/issues/8353?journal_id=551552016-05-20T14:27:41ZJanos Mattyasovszky
<ul><li><strong>Related to</strong> <i><a class="issue tracker-2 status-1 priority-16 priority-default" href="/issues/8352">User story #8352</a>: Create a per-node private-folder for file distribution to each node</i> added</li></ul> Rudder - User story #8353: Implement notifications for different server-side actions and events (hooks)https://issues.rudder.io/issues/8353?journal_id=551712016-05-23T12:14:25ZNicolas CHARLESnicolas.charles@rudder.io
<ul><li><strong>Assignee</strong> changed from <i>Nicolas CHARLES</i> to <i>Jonathan CLARKE</i></li><li><strong>Target version</strong> set to <i>Ideas (not version specific)</i></li></ul><p>This sounds like an awesome idea. I can imagine it can ease a lot integration with other tools.<br />Asigning to Jon for a better qualification of the ticket</p> Rudder - User story #8353: Implement notifications for different server-side actions and events (hooks)https://issues.rudder.io/issues/8353?journal_id=564832016-06-02T19:25:01ZJanos Mattyasovszky
<ul><li><strong>Related to</strong> <i><a class="issue tracker-2 status-6 priority-16 priority-default closed" href="/issues/6562">User story #6562</a>: Have a hook to run a command on non compliance</i> added</li></ul> Rudder - User story #8353: Implement notifications for different server-side actions and events (hooks)https://issues.rudder.io/issues/8353?journal_id=564842016-06-02T19:25:54ZJanos Mattyasovszky
<ul><li><strong>Description</strong> updated (<a title="View differences" href="/journals/56484/diff?detail_id=70510">diff</a>)</li></ul><p>Adding idea of non-compliance hook from <a class="issue tracker-2 status-5 priority-16 priority-default closed parent" title="User story: Implement notifications for different server-side actions and events (hooks) (Released)" href="https://issues.rudder.io/issues/8353">#8353</a></p> Rudder - User story #8353: Implement notifications for different server-side actions and events (hooks)https://issues.rudder.io/issues/8353?journal_id=570312016-06-14T09:29:40ZJanos Mattyasovszky
<ul></ul><p>Another way would be to specify a http(s) endpoint, which then would receive REST Calls on different events.</p>
<p>Example: <a class="external" href="http://docs.gitlab.com/ce/system_hooks/system_hooks.html">http://docs.gitlab.com/ce/system_hooks/system_hooks.html</a></p> Rudder - User story #8353: Implement notifications for different server-side actions and events (hooks)https://issues.rudder.io/issues/8353?journal_id=570322016-06-14T09:30:38ZJanos Mattyasovszky
<ul><li><strong>Subject</strong> changed from <i>Implement server-side hooks for different actions</i> to <i>Implement notifications for different server-side actions and events</i></li></ul> Rudder - User story #8353: Implement notifications for different server-side actions and events (hooks)https://issues.rudder.io/issues/8353?journal_id=591712016-08-22T14:55:46ZFrançois ARMANDfrancois.armand@rudder.io
<ul><li><strong>Subject</strong> changed from <i>Implement notifications for different server-side actions and events</i> to <i>Implement notifications for different server-side actions and events (hooks)</i></li></ul> Rudder - User story #8353: Implement notifications for different server-side actions and events (hooks)https://issues.rudder.io/issues/8353?journal_id=603412016-09-05T12:53:37ZVincent MEMBRÉvme@rudder.io
<ul></ul><p>Some notes:</p>
<ul>
<li>Those hooks should be versionned (stored in rudder configuration repository ? ) </li>
<li>Add some hooks on change Request steps (ie: new Change request => warn reviewers, deployed => warn team what was deployed)</li>
<li>Maybe manage those hooks via web interface</li>
</ul> Rudder - User story #8353: Implement notifications for different server-side actions and events (hooks)https://issues.rudder.io/issues/8353?journal_id=603422016-09-05T13:05:46ZJanos Mattyasovszky
<ul></ul><p>Well, the question is, if you want to run local binary hooks, or send out hooks to (1? n?) REST Endpoints on events?</p>
<p>Please see gitlab's example:</p>
<p><a class="external" href="https://gitlab.com/gitlab-org/gitlab-ce/blob/master/doc/web_hooks/web_hooks.md">https://gitlab.com/gitlab-org/gitlab-ce/blob/master/doc/web_hooks/web_hooks.md</a></p> Rudder - User story #8353: Implement notifications for different server-side actions and events (hooks)https://issues.rudder.io/issues/8353?journal_id=666102016-11-07T08:07:12ZFrançois ARMANDfrancois.armand@rudder.io
<ul><li><strong>Priority</strong> changed from <i>N/A</i> to <i>2</i></li><li><strong>Target version</strong> changed from <i>Ideas (not version specific)</i> to <i>4.1.0~beta1</i></li></ul><p>This will be done in 4.1.</p> Rudder - User story #8353: Implement notifications for different server-side actions and events (hooks)https://issues.rudder.io/issues/8353?journal_id=666112016-11-07T08:07:34ZFrançois ARMANDfrancois.armand@rudder.io
<ul><li><strong>Status</strong> changed from <i>New</i> to <i>In progress</i></li><li><strong>Assignee</strong> changed from <i>Jonathan CLARKE</i> to <i>François ARMAND</i></li></ul> Rudder - User story #8353: Implement notifications for different server-side actions and events (hooks)https://issues.rudder.io/issues/8353?journal_id=666122016-11-07T08:58:20ZFrançois ARMANDfrancois.armand@rudder.io
<ul></ul><p>The first use case/validation step for hooks is to normalize all the shell command we are calling in Rudder, which are as of today:</p>
<p>- from rudder-web.property: rudder.cfengine.reload.server.command: /usr/bin/killall <del>SIGHUP cf-serverd" <br /></del> from rudder-web.property: rudder.{community,nova}.checkpromises.command=/var/rudder/cfengine-community/bin/cf-promises<br />- from class Cf3PromisesFileWriterServiceImpl: correct permission of generated policy files: s"/bin/chmod -R u-x,u+rwX,go-rwx ${baseFolder}"</p>
<p>The last two are executed after policies are generated for a node, but before the new policies are moved from /var/rudder/share/$NODEID/rules.new to /var/rudder/share/$NODEID/rules.</p>
<p>So it seems that we either need to consider that "node-policy-generated" hooks are called before the move, or add a hook dire for that. I'm enclined for the second one, that would allow a per-node-success-generation notification.</p>
<p>We can also pass all updated nodes to policy-generation-finished/ hooks, but that would me sometime several thousand parameters, not sure how sh handle that (or if it's even legit). <br />Or no, even better: policy-generation-finished takes as argument a filename, the filename contains all the generation interesting metrics:</p>
<p>- start/end time of the different operations, <br />- node id/hostname updated, with new configuration id<br />- certainly other things.</p>
<p>So we would have:</p>
<pre>
/opt/rudder/hooks.d/:
-> policy-generation-started/
When a generation start, before we have done anything (safe perhaps snapshoting
node/rule/directives/groups/parameters).
No parameter (or only generation timestamp ?)
Typically to add context information for nodes, like getting properties from CMDB.
-> node-policy-generated/
Called when policies are generated for a node, before atomically replacing (i.e: moving)
/var/rudder/share/$NODEID/rules.new to /var/rudder/share/$NODEID/rules.
Typically used to check things on policies for the node (cf-promises) or get external info
which depends upon node properties or generate signatures.
-> policy-generation-finished/
At the end of the process, the actual last step. Typically used to notify external systems
that new policies are available (ex: notify cf-serverd)
Parameter: a file with updated nodes and perhaps other info (start/end time...)
#more specification for these one needed
-> node-non-compliant/
-> inventory-received/
Inventory received for a node that is not yet managed by Rudder.
-> node-accepted/
When a node is accepted.
-> inventory-updated/
When an inventory is received for a node already managed by Rudder.
</pre> Rudder - User story #8353: Implement notifications for different server-side actions and events (hooks)https://issues.rudder.io/issues/8353?journal_id=666572016-11-07T23:09:54ZFrançois ARMANDfrancois.armand@rudder.io
<ul></ul><p>One more question: what naming convention to use ?</p>
<p>It's nice to be able to add files in these directories which are not hooks (or which are disabled hooks). Typically, conf.d directories, file are names "NN-filename.conf". "NN" is a number to allow standard ordering of hooks (hooks will be executed sequentially, there is far to many things that brokes on a fs tree when parallelized - starting with user expectation :)</p>
<p>Obviously, we can't use ".conf" for exec files. And there is no reason to use ".sh". And ".exe" has a kind of history. So I'm leaning toward ".hook", to keep the symetry hooks.d/xxx.hook // conf.d/xxxx.conf. But it is not nice.</p>
<p>The other solution is to have anything NOT starting by "_" be a hook. But that mean that "readme.txt" is a hook. Not nice.</p>
<p>So, for now I will go with ".hook", and welcome feedback on the subject.</p> Rudder - User story #8353: Implement notifications for different server-side actions and events (hooks)https://issues.rudder.io/issues/8353?journal_id=666582016-11-08T05:46:44ZJanos Mattyasovszky
<ul></ul><p>Hi<br />I'd check for being executable (Readme.txt would only be a valid hook if it had +x, which is also not nice), and/or exclude the <code>.files</code> or <code>files~</code><br />OTOH I could also live with .hook :-)</p> Rudder - User story #8353: Implement notifications for different server-side actions and events (hooks)https://issues.rudder.io/issues/8353?journal_id=666592016-11-08T05:58:13ZJanos Mattyasovszky
<ul><li><strong>Description</strong> updated (<a title="View differences" href="/journals/66659/diff?detail_id=83675">diff</a>)</li></ul><p>I'd propose <code>inventory-received</code> to be more like <code>inventory-first-received</code>, this would be a bullet proof naming and not confuse people not knowing the docs by heart.</p>
<p>I'd also see what you think about having the possibility of <code>hook.async</code> files, which you don't have to wait for, do trigger in order but do you not wait for to finish completion. These would be good to do some off-server actions that do not not influence the in-rudder actions in any way.</p>
<p>This also brings me to the question of the return code. Do you plan to have different behavior depending on the return code? <br />Like for example:</p>
<blockquote>
<p>0= pass, 1= fail, 2= warn, 254= explode?</p>
</blockquote> Rudder - User story #8353: Implement notifications for different server-side actions and events (hooks)https://issues.rudder.io/issues/8353?journal_id=666602016-11-08T07:16:22ZJonathan CLARKEjonathan.clarke@normation.com
<ul></ul><p>François ARMAND wrote:</p>
<blockquote>
<p>One more question: what naming convention to use ?</p>
<p>It's nice to be able to add files in these directories which are not hooks (or which are disabled hooks). Typically, conf.d directories, file are names "NN-filename.conf". "NN" is a number to allow standard ordering of hooks (hooks will be executed sequentially, there is far to many things that brokes on a fs tree when parallelized - starting with user expectation :)</p>
<p>Obviously, we can't use ".conf" for exec files. And there is no reason to use ".sh". And ".exe" has a kind of history. So I'm leaning toward ".hook", to keep the symetry hooks.d/xxx.hook // conf.d/xxxx.conf. But it is not nice.</p>
</blockquote>
<p>I'd prefer the reverse logic: try and execute everything except files that have an extension in a list, including .disabled,.new,.old,.txt,...</p>
<blockquote>
<p>The other solution is to have anything NOT starting by "_" be a hook. But that mean that "readme.txt" is a hook. Not nice.</p>
</blockquote>
<p>Ugh.</p> Rudder - User story #8353: Implement notifications for different server-side actions and events (hooks)https://issues.rudder.io/issues/8353?journal_id=666612016-11-08T07:30:35ZJonathan CLARKEjonathan.clarke@normation.com
<ul></ul><p>Some ideas about your proposal for hooks.</p>
<p>/opt/rudder/hooks.d/:<br /> -> policy-generation-started/<br /> When a generation start, before we have done anything (safe perhaps snapshot in node/rule/directives/groups/parameters). <br /> No parameter (or only generation timestamp ?)<br /> Typically to add context information for nodes, like getting properties from CMDB.</p>
<p>Looks good. I can think of one useful parameter: a structure representing all the nodes and their policy servers that are going to have promises generated. That could be useful to pre-fetch properties from CMDB and ensure they are OK on <strong>all</strong> nodes. </p>
<pre><code>-> node-policy-generated/<br /> Called when policies are generated for a node, before atomically replacing (i.e: moving) <br /> /var/rudder/share/$NODEID/rules.new to /var/rudder/share/$NODEID/rules.<br /> Typically used to check things on policies for the node (cf-promises) or get external info<br /> which depends upon node properties or generate signatures.</code></pre>
<p>This should be named consistently with the others in its category, so something like policy-generation-node-ready</p>
<p>I think we should also add a policy-generation-node-finished that would be called <strong>after</strong> the mv. That could be useful to trigger immediate actions that require the new promises, on a node by node basis, such as copying promises to a relay server. </p>
<pre><code>-> policy-generation-finished/<br /> At the end of the process, the actual last step. Typically used to notify external systems<br /> that new policies are available (ex: notify cf-serverd)<br /> Parameter: a file with updated nodes and perhaps other info (start/end time...)</code></pre>
<pre><code>#more specification for these one needed<br /> -> node-non-compliant/</code></pre>
<pre><code>-> inventory-received/<br /> Inventory received for a node that is not yet managed by Rudder.</code></pre>
<p>As Janos says this could be clearer. I'm not sure it's really anything to do with inventories, though. Today, we rely on inventories to submit a new node, but there are often ideas about adding nodes that don't have an agent. They obviously wouldn't have an inventory but are still new nodes we may want to run hooks on.</p>
<p>How about node-pending-new? </p>
<pre><code>-> node-accepted/<br /> When a node is accepted.</code></pre>
<p>And therefore node-pending-accepted </p>
<pre><code>-> inventory-updated/<br /> When an inventory is received for a node already managed by Rudder.</code></pre>
<p>This case makes sense for the term inventory. I propose node-inventory-updated.</p>
<p>It would be useful to have setting-allowed-network-updated too, for example to be able to adjust firewall rules automatically.</p> Rudder - User story #8353: Implement notifications for different server-side actions and events (hooks)https://issues.rudder.io/issues/8353?journal_id=666662016-11-08T08:42:12ZBenoît PECCATTEbenoit.peccatte@rudder.io
<ul></ul><p>About .hook extension:</p>
<p>No we should not detect a file type based on an extension, this is windowsish, error prone and awkward for unix people.</p>
<p>The proper extension for an executable file is nothing.</p>
<p>I think the executable bit suggested by Janos is a good solution.<br />The readme should not be executable.<br />.old and .new should not exist <br />disabled files could be set non-executable</p> Rudder - User story #8353: Implement notifications for different server-side actions and events (hooks)https://issues.rudder.io/issues/8353?journal_id=668232016-11-11T22:58:37ZFrançois ARMANDfrancois.armand@rudder.io
<ul><li><strong>Status</strong> changed from <i>In progress</i> to <i>Pending technical review</i></li><li><strong>Assignee</strong> changed from <i>François ARMAND</i> to <i>Nicolas CHARLES</i></li><li><strong>Pull Request</strong> set to <i>https://github.com/Normation/rudder/pull/1374</i></li></ul><p>PR <a class="external" href="https://github.com/Normation/rudder/pull/1374">https://github.com/Normation/rudder/pull/1374</a></p> Rudder - User story #8353: Implement notifications for different server-side actions and events (hooks)https://issues.rudder.io/issues/8353?journal_id=668242016-11-11T22:59:26ZFrançois ARMANDfrancois.armand@rudder.io
<ul><li><strong>Assignee</strong> changed from <i>Nicolas CHARLES</i> to <i>Jonathan CLARKE</i></li></ul> Rudder - User story #8353: Implement notifications for different server-side actions and events (hooks)https://issues.rudder.io/issues/8353?journal_id=672632016-11-15T12:06:52ZOlivier Maurasolivier@mauras.ch
<ul></ul><p>While I like the idea to have a "Cobbler like" hook/trigger system, I can't help but think that it would be more flexible if this would be plugged to a message bus or any system that can be used as is like etcd or consul.</p>
<p>There's much possibilities available if it's possible to listen to these events from an external source - Specifically when talking about multiple "real time notifications"</p> Rudder - User story #8353: Implement notifications for different server-side actions and events (hooks)https://issues.rudder.io/issues/8353?journal_id=672762016-11-15T17:10:29ZFrançois ARMANDfrancois.armand@rudder.io
<ul><li><strong>Assignee</strong> changed from <i>Jonathan CLARKE</i> to <i>Nicolas CHARLES</i></li></ul> Rudder - User story #8353: Implement notifications for different server-side actions and events (hooks)https://issues.rudder.io/issues/8353?journal_id=672772016-11-16T05:31:22ZJanos Mattyasovszky
<ul></ul><p>Olivier Mauras wrote:</p>
<blockquote>
<p>There's much possibilities available if it's possible to listen to these events from an external source - Specifically when talking about multiple "real time notifications"</p>
</blockquote>
<p>You are so right. But this as a first step might be only a couple of talks from somethink like <a class="external" href="https://developer.github.com/webhooks/">https://developer.github.com/webhooks/</a> away. Having something like a message bus is like choosing between vi or emacs: almost impossible, but if you have a standardized set of events and parameters, you actually could trigger outside events from CLI based on these hooks...</p> Rudder - User story #8353: Implement notifications for different server-side actions and events (hooks)https://issues.rudder.io/issues/8353?journal_id=672812016-11-16T09:57:35ZOlivier Maurasolivier@mauras.ch
<ul></ul><p>Other projects have proven that it's fairly easy to implement multiple message bus protocols support. Let's break it down to:<br />- 0mq<br />- Etcd<br />- Consul</p>
<p>Code base for Etcd and Consul should be pretty similar aside from the connectors and this opens a broad range of new features in the future...</p> Rudder - User story #8353: Implement notifications for different server-side actions and events (hooks)https://issues.rudder.io/issues/8353?journal_id=672862016-11-17T15:06:11ZFlorian Heigl
<ul></ul><p>0mq is what martin had used in his IoT coupling.<br />If you want to get very rich... this is relevant :-)</p> Rudder - User story #8353: Implement notifications for different server-side actions and events (hooks)https://issues.rudder.io/issues/8353?journal_id=673162016-11-18T14:04:37ZFrançois ARMANDfrancois.armand@rudder.io
<ul><li><strong>Assignee</strong> changed from <i>Nicolas CHARLES</i> to <i>Jonathan CLARKE</i></li></ul> Rudder - User story #8353: Implement notifications for different server-side actions and events (hooks)https://issues.rudder.io/issues/8353?journal_id=673172016-11-18T14:07:55ZFrançois ARMANDfrancois.armand@rudder.io
<ul><li><strong>Assignee</strong> changed from <i>Jonathan CLARKE</i> to <i>Nicolas CHARLES</i></li></ul> Rudder - User story #8353: Implement notifications for different server-side actions and events (hooks)https://issues.rudder.io/issues/8353?journal_id=673702016-11-21T22:12:02ZFrançois ARMANDfrancois.armand@rudder.io
<ul><li><strong>Assignee</strong> changed from <i>Nicolas CHARLES</i> to <i>Jonathan CLARKE</i></li></ul> Rudder - User story #8353: Implement notifications for different server-side actions and events (hooks)https://issues.rudder.io/issues/8353?journal_id=673712016-11-21T23:20:17ZFrançois ARMANDfrancois.armand@rudder.io
<ul><li><strong>Status</strong> changed from <i>Pending technical review</i> to <i>In progress</i></li><li><strong>Assignee</strong> changed from <i>Jonathan CLARKE</i> to <i>François ARMAND</i></li></ul><p>@Olivier: having an event bus would be really nice, but it's order of magnitude more work than the scope of that feature. On the other hand, as Janos said, it should be quite simple to use a cli to genererate event from the hook.</p>
<p><a class="user active user-mention" href="https://issues.rudder.io/users/309">@Janos Matya</a>: ok for testing the exec bit.</p>
<p><a class="user active user-mention" href="https://issues.rudder.io/users/309">@Janos Matya</a>: for the async one: why not. What would be the naming convention ? But there is no order notion for async, they are all started concurrently (even if implementation give them an order, it must not be relevant for the user).</p>
<p><a class="user active user-mention" href="https://issues.rudder.io/users/309">@Janos Matya</a>: For the return code, for now, without async, it was easy: 0 pass, other: error and stop the generation for that node (and with today scheme, the whole generation). That does not hold with async one, where the semantic must become something like:</p>
<p>- start all async, <br />- execute the pipeline of sync one, <br />- wait for all to terminate, either successfully or note. If an error exists in any async or for the pipeline, stop with the error.</p>
<p>I didn't thought to the "warn only" case, which seems extremely useful. What is a standard error code semantic? I was really liking the fact that any non-0 would be an error (no surprise for the user, allows to use third party software without checking that error code is in the correct bounds beside 0 for success which is standard. And he would have access to several error codes). What about: 0: success, > 0: error, < 0 : warn only?</p>
<p>An other problem is that for now, we don't have anything to keep a warn message about policy generation and display it at the end of the process (policy generation is either success or error, no warn). We can log it, thought, and have an other user story to display warning messages on generation.</p>
<p>@Jon / <a class="user active user-mention" href="https://issues.rudder.io/users/309">@Janos Matya</a> regarding naming convention: ok.</p>
<p>@Jon: For the post-mv hook: I wasn't sure of it's utility. We have the policy-generated with all updated nodes which allows batch and per-node process. I'm not sure of the added value of having the post-mv, too. But well, that does not cost much more, and users are creative.</p>
<p>For inventory related hooks, I need more thoughts. I will finish the first set on policy-generation to validate all the ideas here. <br />(reason for inventory: I want the hooks to be in rudder-webapp, not in ldap-inventory web app to be able to have the same hooks executed for node properties and other data sources updated. For that to work, it must be on rudder side. But linking node creation/inventory update/etc to rudder is hard, as testimonify <a class="issue tracker-1 status-5 priority-6 priority-low2 closed" title="Bug: Node (hostname,policyserver,...) modification should trigger promises regeneration (Released)" href="https://issues.rudder.io/issues/1411">#1411</a>).</p>
<p>That also mean that the hook name should not be "inventory-updated", but "node-info-updated" (inventories, or properties, or dataset from datasource as in <a class="issue tracker-2 status-5 priority-16 priority-default closed parent" title="User story: Import node properties from external data sources (Released)" href="https://issues.rudder.io/issues/9698">#9698</a>)</p> Rudder - User story #8353: Implement notifications for different server-side actions and events (hooks)https://issues.rudder.io/issues/8353?journal_id=673822016-11-22T08:45:21ZJanos Mattyasovszky
<ul></ul><p>François ARMAND wrote:</p>
<blockquote>
<p><a class="user active user-mention" href="https://issues.rudder.io/users/309">@Janos Matya</a>: for the async one: why not. What would be the naming convention ? But there is no order notion for async, they are all started concurrently (even if implementation give them an order, it must not be relevant for the user).</p>
</blockquote>
<p>Well, with the current way I could also implement a "poor man's async" way by forking away and returning non-error, where for example I just have to do some housekeeping, that does not influence anything on rudder's side, so I can do this in the background (I also could just use the hook to send a notification to a message bus or an external API that would then to all the async processing if necessary).</p>
<blockquote>
<p><a class="user active user-mention" href="https://issues.rudder.io/users/309">@Janos Matya</a>: For the return code, for now, without async, it was easy: 0 pass, other: error and stop the generation for that node (and with today scheme, the whole generation). That does not hold with async one, where the semantic must become something like:</p>
</blockquote>
<blockquote>
<p>- start all async, <br />- execute the pipeline of sync one, <br />- wait for all to terminate, either successfully or note. If an error exists in any async or for the pipeline, stop with the error.</p>
<p>I didn't thought to the "warn only" case, which seems extremely useful. What is a standard error code semantic? I was really liking the fact that any non-0 would be an error (no surprise for the user, allows to use third party software without checking that error code is in the correct bounds beside 0 for success which is standard. And he would have access to several error codes). What about: 0: success, > 0: error, < 0 : warn only?</p>
</blockquote>
<p>You don't have <0 exit codes :-) they go from 0 to 255 AFAIK</p>
<p>I would at least reserve some exit codes for future use, so you can extend functionality later (because if you define other:error, you'd have to break this specification later, instead if you say "0:pass, 1:error, >1:error, but later subject for possible change", that would not make it that hard to implement new functions, and it is only a documentational thing :)</p>
<blockquote>
<p>@Jon: For the post-mv hook: I wasn't sure of it's utility. We have the policy-generated with all updated nodes which allows batch and per-node process. I'm not sure of the added value of having the post-mv, too. But well, that does not cost much more, and users are creative.</p>
</blockquote>
<p>Yes please, you'd be surprised by the creativity some little feature can generate :-)</p> Rudder - User story #8353: Implement notifications for different server-side actions and events (hooks)https://issues.rudder.io/issues/8353?journal_id=674142016-11-22T16:18:59ZFrançois ARMANDfrancois.armand@rudder.io
<ul><li><strong>Related to</strong> <i><a class="issue tracker-1 status-6 priority-16 priority-default closed" href="/issues/9704">Bug #9704</a>: As for Rudder 3.2.9, promises calculation is still too slow</i> added</li></ul> Rudder - User story #8353: Implement notifications for different server-side actions and events (hooks)https://issues.rudder.io/issues/8353?journal_id=674692016-11-23T12:05:14ZFrançois ARMANDfrancois.armand@rudder.io
<ul></ul><p><a class="user active user-mention" href="https://issues.rudder.io/users/309">@Janos Matya</a>: Ah yes, too much java. Of course exit code are positive. So yes, we need to partition the space, and reserve some for future extension, and as we are at it, I can add the succes-but-warn. In fact, I could even add a "success but log at debug", "success but log at info", "success but log warn".</p>
<p>We could have 0: success, 1: log debug, 2: log info; 3: log warn, 4-63: errors; <br />And 64-255: reserved (error for now, but with a specific message explaining that you shall not use that because in the future, it may have a different semantic). <br />But that seem quite non conventionnal and surprising given standard unix convention.</p> Rudder - User story #8353: Implement notifications for different server-side actions and events (hooks)https://issues.rudder.io/issues/8353?journal_id=676012016-12-01T10:36:10ZFrançois ARMANDfrancois.armand@rudder.io
<ul></ul><p>So, the implementation will be:</p>
<pre>
Errors code on hooks are interpreted as follow:
- 0 : success, no log (appart if debug one) , continue to next hook
- 1-31 : error , error log in /var/log/rudder/webapp/, stop processing
- 32-63 : warning, warning log in /var/log/rudder/webapp/, continue to next hook
- 64-255: reserved for futur use case. Behavior may change without notice.
</pre>
<p>It seems really more conventional to be able to use "1" as an error code.</p> Rudder - User story #8353: Implement notifications for different server-side actions and events (hooks)https://issues.rudder.io/issues/8353?journal_id=676082016-12-01T11:03:54ZFrançois ARMANDfrancois.armand@rudder.io
<ul><li><strong>Assignee</strong> changed from <i>François ARMAND</i> to <i>Jonathan CLARKE</i></li></ul> Rudder - User story #8353: Implement notifications for different server-side actions and events (hooks)https://issues.rudder.io/issues/8353?journal_id=682112016-12-06T16:15:53ZFrançois ARMANDfrancois.armand@rudder.io
<ul><li><strong>Status</strong> changed from <i>In progress</i> to <i>Pending release</i></li><li><strong>% Done</strong> changed from <i>0</i> to <i>100</i></li></ul><p>Applied in changeset <a class="changeset" title="Fixes #8353: implements hooks for policy generation" href="https://issues.rudder.io/projects/rudder/repository/rudder/revisions/6f7791d45ba77e6049a779e9b3d67a79936df0e4">rudder|6f7791d45ba77e6049a779e9b3d67a79936df0e4</a>.</p> Rudder - User story #8353: Implement notifications for different server-side actions and events (hooks)https://issues.rudder.io/issues/8353?journal_id=694812017-01-17T16:07:30ZVincent MEMBRÉvme@rudder.io
<ul><li><strong>Status</strong> changed from <i>Pending release</i> to <i>Released</i></li></ul><p>This bug has been fixed in Rudder 4.1.0 which was released today.</p>
<ul>
<li>4.1.0: <a href="http://www.rudder-project.org/pipermail/rudder-announce/2017-January/000216.html" class="external">Announce</a> <a href="http://www.rudder-project.org/changelog-4.1" class="external">Changelog</a></li>
<li>Download: <a class="external" href="https://www.rudder-project.org/site/get-rudder/downloads/">https://www.rudder-project.org/site/get-rudder/downloads/</a></li>
</ul> Rudder - User story #8353: Implement notifications for different server-side actions and events (hooks)https://issues.rudder.io/issues/8353?journal_id=705062017-02-13T15:53:01ZFrançois ARMANDfrancois.armand@rudder.io
<ul><li><strong>Related to</strong> <i><a class="issue tracker-1 status-6 priority-16 priority-default closed" href="/issues/9863">Bug #9863</a>: Hook execution logs should not be displayed in default verbosity</i> added</li></ul> Rudder - User story #8353: Implement notifications for different server-side actions and events (hooks)https://issues.rudder.io/issues/8353?journal_id=761952017-05-09T14:35:31ZFrançois ARMANDfrancois.armand@rudder.io
<ul><li><strong>Related to</strong> <i><a class="issue tracker-2 status-5 priority-16 priority-default closed parent" href="/issues/10568">User story #10568</a>: Create a hook for pre and post node deletion event</i> added</li></ul> Rudder - User story #8353: Implement notifications for different server-side actions and events (hooks)https://issues.rudder.io/issues/8353?journal_id=762092017-05-10T09:38:14ZFrançois ARMANDfrancois.armand@rudder.io
<ul><li><strong>Related to</strong> <i><a class="issue tracker-2 status-6 priority-16 priority-default closed" href="/issues/10724">User story #10724</a>: adding a Hook after node validation</i> added</li></ul>