[ClusterLabs Developers] Proposed future feature: multiple notification scripts

[Andrew Beekhof]

> On 3 Dec 2015, at 10:23 AM, Ken Gaillot <kgaillot at redhat.com> 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.

Actually, that didn't make it into an upstream release.
So we could just pretend it never happened :)

Sure its in RHEL but we haven’t advertised it yet and it can be our problem to do backwards compatibility for - no need to inflict that on upstream.

> 
> 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).
> 
> 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.
> -- 
> Ken Gaillot <kgaillot at redhat.com>
> 
> _______________________________________________
> Developers mailing list
> Developers at clusterlabs.org
> http://clusterlabs.org/mailman/listinfo/developers