[ClusterLabs Developers] Proposed future feature: multiple notification scripts

[Digimer]

On 02/12/15 06:23 PM, Ken Gaillot wrote:
> This will be of interest to cluster front-end developers and anyone who
> needs event notifications ...
> 
> One of the new features in Pacemaker 1.1.14 will be built-in
> notifications of cluster events, as described by Andrew Beekhof on That
> Cluster Guy blog:
> http://blog.clusterlabs.org/blog/2015/reliable-notifications/
> 
> For a future version, we're considering extending that to allow multiple
> notification scripts, each with multiple recipients. This would require
> a significant change in the CIB. Instead of a simple cluster property,
> our current idea is a new configuration section in the CIB, probably
> along these lines:
> 
> <configuration>
>    <!-- usual crm_config etc. here -->
> 
>    <!-- this is the new section -->
>    <notifications>
> 
>       <!-- each script would be in a notify element -->
>       <notify id="notify-1" path="/my/script.sh" timeout="30s">
> 
>          <recipient id="recipient-1" value="me at example.com" />
>          <!-- etc. for multiple recipients -->
> 
>       </notify>
> 
>       <!-- etc. for multiple scripts -->
> 
>    </notifications>
> </configuration>
> 
> 
> The recipient values would be passed to the script as command-line
> arguments (ex. "/my/script.sh me at example.com").
> 
> For backward compatibility, the (brand new!) notification-agent and
> notification-recipient cluster properties would be kept as deprecated
> shortcuts for a single notify script and recipient.
> 
> Also for backward compatibility, the first recipient would be passed to
> the script as the CRM_notify_recipient environment variable.
> 
> This proposal came about because the new notification capability has
> turned out to be useful enough that people sometimes want to use it for
> multiple purposes, e.g. email an administrator, and notify some software
> that an event occurred. Trying to fit unrelated actions in one
> notification script (or a script that calls multiple other scripts) has
> obvious pitfalls, so this would make it easier on sysadmins.
> 
> Another advantage will be a configurable timeout (1.1.14 will have a
> hardcoded 5-minute timeout for notification scripts).

In ScanCore, we handled this by delivering to a locally configured
postfix instance. This handles queueing and delivery without the
higher-level app needing to worry about it.

(unless I am misunderstanding "timeout" in this context...)

> The crm_attribute command and the various cluster front-ends would need
> to be modified to handle the new configuration syntax.
> 
> This is all in the idea stage (development is still a ways off), so any
> comments, suggestions, criticisms, etc. are welcome.

Would it be up to the called script to craft the message, or would the
message be generated by pacemaker? If the later; How would you handle
internationalization?

Event-driven alerts is a fantastic idea. :D

-- 
Digimer
Papers and Projects: https://alteeve.ca/w/
What if the cure for cancer is trapped in the mind of a person without
access to education?