[ClusterLabs] ClusterLabsComing in 1.1.15: Event-driven alerts

[Ken Gaillot]

On 04/22/2016 05:19 AM, Klaus Wenninger wrote:
> On 04/22/2016 10:55 AM, Ferenc Wágner wrote:
>> Ken Gaillot <kgaillot at redhat.com> writes:
>>
>>> Each alert may have any number of recipients configured. These values
>>> will simply be passed to the script as arguments. The first recipient
>>> will also be passed as the CRM_alert_recipient environment variable,
>>> for compatibility with existing scripts that only support one
>>> recipient.
>>> [...]
>>> In the current implementation, meta-attributes and instance attributes
>>> may also be specified within the <recipient> block, in which case they
>>> override any values specified in the <alert> block when sent to that
>>> recipient.
>> Sorry, I don't get this.  The first paragraph above tells me that for a
>> given cluster event each <alert> is run once, with all recipients passed
>> as command line arguments to the alert executable.  But a single
>> invocation can only have a single set of environmental variables, so how
>> can you override instance attributes for individual recipients?
> The paragraph above is indeed confusing or at least it can
> be understood in a way that doesn't reflect how it is implemented.
> If the script would just be called once the parameter itself
> could already be a list.
> Anyway - as it is implemented at the moment - the script is called
> for each of the recipients in parallel.
> This has a couple of advantages as it simplifies the script
> implementation (if you have problems with concurrency use just
> one recipient and make it a list), the timeout can be observed
> on a per recipient basis and if delivering to one recipient fails
> it doesn't affect the others.
> And each of these calls inherits a global set of environment
> variables while each of them can be overwritten on a per
> recipient basis.

Sorry, that was my confusion -- an earlier design had all recipients
being passed to one call of the script, but we ended up doing one call
per recipient, as Klaus describes above.

I still have mixed feelings about that decision, since it's more
overhead spawning a process per recipient, but it's more compatible with
existing scripts that only handle one recipient, and it allows all
notifications to be fired off in parallel.

If anyone is concerned about the overhead, they can write their script
such that multiple recipients can be put in a single recipient field as
Klaus suggests above (for example, a comma-separated list of email
addresses).

>>> Whether this stays in the final 1.1.15 release or not depends on
>>> whether people find this to be useful, or confusing.
>> Now guess..:)
> Like this it finally even might lead to detection and avoidance of
> confusion ;-)

And to be clear, alerts will definitely be included in the final 1.1.15
-- the only question is whether to include per-recipient attributes.

One possibility is to support per-recipient attributes in the XML, but
not in the higher-level tools. That way, advanced users can configure it
if they want, without complicating the commands (and troubleshooting and
support) needed by most users.