[ClusterLabs Developers] Proposed future feature: multiple notification scripts

[Ken Gaillot]

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).

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>