Re: [ClusterLabs Developers] Proposed future feature: multiple notification scripts

2015-12-02 Thread 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:
> 
> 
>
> 
>
>
> 
>   
>   
> 
>  
>  
> 
>   
> 
>   
> 
>
> 
> 
> 
> The recipient values would be passed to the script as command-line
> arguments (ex. "/my/script.sh m...@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?

___
Developers mailing list
Developers@clusterlabs.org
http://clusterlabs.org/mailman/listinfo/developers

[ClusterLabs Developers] FYI: Getting ready for pacemaker 1.1.14rc1

2015-12-02 Thread Ken Gaillot 
Hello everyone,

We're looking at starting the 1.1.14 release cycle soon (aiming to get
rc1 out next week). If anyone has fixes or features in progress that
they want to get in 1.1.14, let me know, and I'll plan accordingly. Of
course, new stuff can get in anytime for the next release after that.
-- 
Ken Gaillot 

___
Developers mailing list
Developers@clusterlabs.org
http://clusterlabs.org/mailman/listinfo/developers

[ClusterLabs Developers] Proposed future feature: multiple notification scripts

2015-12-02 Thread 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:


   

   
   

  
  

 
 

  

  

   



The recipient values would be passed to the script as command-line
arguments (ex. "/my/script.sh m...@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 

___
Developers mailing list
Developers@clusterlabs.org
http://clusterlabs.org/mailman/listinfo/developers

Re: [ClusterLabs Developers] Proposed future feature: multiple notification scripts

2015-12-02 Thread Andrew Beekhof 

> On 3 Dec 2015, at 10:23 AM, 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:
> 
> 
>   
> 
>   
>   
> 
>  
>  
> 
> 
> 
> 
>  
> 
>  
> 
>   
> 
> 
> 
> The recipient values would be passed to the script as command-line
> arguments (ex. "/my/script.sh m...@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 
> 
> ___
> Developers mailing list
> Developers@clusterlabs.org
> http://clusterlabs.org/mailman/listinfo/developers


___
Developers mailing list
Developers@clusterlabs.org
http://clusterlabs.org/mailman/listinfo/developers