[ClusterLabs] Coming in 1.1.15: Event-driven alerts
Lars Marowsky-Bree
lmb at suse.com
Mon Apr 25 11:00:10 UTC 2016
On 2016-04-21T12:50:43, Ken Gaillot <kgaillot at redhat.com> wrote:
Hi all,
awesome to see such a cool new feature land! I do have some
questions/feedback though.
> The alerts section can have any number of alerts, which look like:
>
> <alert id="alert-1"
> path="/srv/pacemaker/pcmk_alert_sample.sh">
>
> <recipient id="alert-1-recipient-1"
> value="/var/log/cluster-alerts.log" />
>
> </alert>
So, there's one bit of this I dislike - instance_attributes get passed
via the environment (as always), but the "value" ends up on the
command-line in ARGV[]? Why?
Wouldn't it make more sense to have an alert-wide instance_attribute
section within <alert>, that could be overridden on a per-recipient
basis if needed? And drop the value entirely?
Having things in ARGV[] is always risky due to them being exposed more
easily via ps. Environment variables or stdin appear better.
What I also miss is the ability to filter the events (at least
coarsely?) sent to a specific alert/recipient, and to constraint on
which nodes it will get executed. Is that going to happen? On a busy
cluster, this could easily cause significant load otherwise.
It's also worth pointing out that this could likely "lose" events during
fail-overs, DC crashes, etc. Users probably should not strictly rely on
seeing *every* alert in their scripts, so this should be carefully
documented to not be considered a transactional, reliable message bus.
Regards,
Lars
--
Architect SDS
SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg)
"Experience is the name everyone gives to their mistakes." -- Oscar Wilde
More information about the Users
mailing list