> On 3 Dec 2015, at 4:14 PM, Digimer <li...@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="m...@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 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…)
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@clusterlabs.org > http://clusterlabs.org/mailman/listinfo/developers _______________________________________________ Developers mailing list Developers@clusterlabs.org http://clusterlabs.org/mailman/listinfo/developers