[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