On 04/25/2016 08:03 AM, Kristoffer Grönlund wrote: > Ken Gaillot <[email protected]> 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 > _______________________________________________ Users mailing list: [email protected] http://clusterlabs.org/mailman/listinfo/users Project Home: http://www.clusterlabs.org Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf Bugs: http://bugs.clusterlabs.org
