[ClusterLabs] Coming in 1.1.15: Event-driven alerts

[Klaus Wenninger]

On 04/25/2016 08:03 AM, Kristoffer Grönlund wrote:
> Ken Gaillot <kgaillot at redhat.com> writes:
>
>> Hello everybody,
>>
>> The release cycle for 1.1.15 will be started soon (hopefully tomorrow)!
>>
>> The most prominent feature will be Klaus Wenninger's new implementation
>> of event-driven alerts -- the ability to call scripts whenever
>> interesting events occur (nodes joining/leaving, resources
>> starting/stopping, etc.).
> Hi, and happy to see this! Looks like a potentially very useful feature.
>
> I started experimenting with support for alerts in crm, and have some
> (very minor) nits/comments.
>
>> The meta-attributes are optional properties used by the cluster.
>> Currently, they include "timeout" (which defaults to 30s) and
>> "tstamp_format" (which defaults to "%H:%M:%S.%06N", and is a
>> microsecond-resolution timestamp provided to the alert script as the
>> CRM_alert_timestamp environment variable).
> Is "tstamp_format" correct? All the other meta attributes are
> in-this-format, so "tstamp-format" would be preferrable to
> maintain consistency. Personally, I'd prefer "timestamp-format", but
> that's veering into bikeshed territory...
You have a point here. tstamp_format was there before the
insight that there were a couple of attributes that belonged
to kind of the same family as those grouped as
meta-attributes when we look at resources.
Probably still early enough to change it.
I would as well prefer timestamp-format as the correlation
with the variable CRM_alert_timestamp seems more
natral then.

>> 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. Whether this stays in the final 1.1.15 release or not depends
>> on whether people find this to be useful, or confusing.
> Do you have any current use for this? My immediate thought is that
> allowing rule expressions in the <alert> level meta and instance
> attributes would be both more expressive and less confusing.
Do you refer to the global idea of repeated recipient-sections here or
just to the overwriting of instance/meta-attributes of the alert-section
by those in the recipient-section?

A guy on the list was complaining that it was called recipient & value
reading the example logging to a log-file. So an instance-attribute called
logfile could be an example.
Certain recipients (whatever a recipient might be ...) might react
quicker and others might be more lame so a timeout per recipient
might make sense.
In cases of recipients being email-destination-addresses it might
be interesting to be able to as well specify a sender-address or
an smtp-server to use.
Could you give examples for how you would like to use rule-expressions -
especially if you want to replace the recipient-sections...

> Cheers,
> Kristoffer
>