[ClusterLabs Developers] Proposed future feature: multiple notification scripts

[Andrew Beekhof]

> On 3 Dec 2015, at 4:14 PM, Digimer <lists at alteeve.ca> wrote:
> 
> 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…)

how long the script can take

> 
>> 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,

yes because pacemaker has (and wants) no knowledge of the transport (SMS, vs email vs. snmp etc)

> 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?
> 
> _______________________________________________
> Developers mailing list
> Developers at clusterlabs.org
> http://clusterlabs.org/mailman/listinfo/developers