[ClusterLabs Developers] Proposed future feature: multiple notification scripts

[Jan Pokorný]

On 07/12/15 09:41 +1100, Andrew Beekhof wrote:
>> On 5 Dec 2015, at 4:22 AM, Ken Gaillot <kgaillot at redhat.com> wrote:
>> On 12/04/2015 10:59 AM, Jan Pokorný wrote:
>>> (would the exec
>>> mechanism apply some kind of rate-limiting to prevent exhaustion?),
>>> but what about
>> 
>> There is no rate limiting on the Pacemaker end. If there winds up
>> being a big demand for it, we can look into it, but that is more
>> likely to be useful within the script itself (a script that notifies
>> another service of status changes likely does not want rate limiting,
>> but an SMS notifier sure might).
> 
> agreed. this belongs in the scripts or some intermediate party.

More deeper reasoning behind the rate limiting question was that if
a fork-exec-forget style is to be applied, you can easily lose
the event ordering (be it due to a bad scheduler, high load
or not covering the machine with a tin foil hat) which may or
may not be acceptable in some cases.

[...]

>>> long-lived unix sockets or named pipes?  Especially the latter
>>> might be doable in the agent just in shell + coreutils and other
>>> basic tooling and might play well with file discovery approach.
>> 
>> Simple shell scripts are often the limit of sysadmins' abilities in
>> this area, so the less they have to know/do the better.

Under normal circumstances, such long-lived connections would ensure
the correct event ordering.  Alternatively, the same effect would be
achieved with fork-exec-wait style with per-script queues (and some
kind of limiting anyway).

-- 
Jan (Poki)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <https://lists.clusterlabs.org/pipermail/developers/attachments/20151212/bfbfbcfb/attachment-0004.sig>