[ClusterLabs Developers] Proposed future feature: multiple notification scripts

[Lars Ellenberg]

On Thu, Dec 03, 2015 at 12:56:36PM -0600, Ken Gaillot wrote:
> On 12/03/2015 10:58 AM, Klaus Wenninger wrote:
> > On 12/03/2015 05:39 PM, Jan Pokorný wrote:
> >> On 03/12/15 17:06 +0100, Klaus Wenninger wrote:
> >>> On 12/03/2015 04:45 PM, Jan Pokorný wrote:
> >>>> What I am up to is a proposal of an alternative/parallel mechanism
> >>>> that better fits the asymmetric (and asynchronous from cluster life
> >>>> cycle POV) use cases: old good drop-in files.  There would simply
> >>>> be a dedicated directory (say /usr/share/pacemaker/notify.d) where
> >>>> the software interested in notifications would craft it's own
> >>>> listener script (or a symlink thereof), script is then discovered
> >>>> by Pacemaker upon subsequent dir rescan or inotify event, done.
> 
> I wouldn't want to introduce a dependency on inotify (especially since
> we support non-Linux OSes), and scanning a directory is an expensive
> operation. We definitely wouldn't want to do rescan for every cluster
> event. Possibly every recheck-interval would be OK. So one question is
> how do we trigger a rescan, and whether that might lead to confusion as
> to why a drop-in isn't (immediately) working.
> 
> But I do think it's an interesting approach worth exploring.

Why. Don't put that burden on Pacemaker.

If someone wants this,
have pacemaker call out to one "master" script,
which then does something similar as "run-parts",
with whatever is "there" at that point.

Passing through arguments/environment/whatever.

Implement one such "example" script,
and maybe ship it together with agents, maybe at
/usr/lib/ocf/notification/pacemaker/run-parts

Craft a few other example notify scripts which would just send a
standardized email blob, or snmp or whatever, which could be used either
directly (instead of the "run-parts" thingy, or via the "run-parts"
thing by "symlinking" them in place.
Should work just the same,
if we cleanly pass through environment and arguments.

Have users contribute their solutions.

> >>>> --> no configuration needed (or is external to the CIB, or is
> >>>>     interspersed in a non-invasive way there), install and go

Exactly.
If you want this, you call just one script, which is part of the
pacemaker infrastructure, and as such in place on every node.
If you then chose to put different "sub" scripts in place
on different nodes, that will be your responsibility.

> >>> Why a dedicated directory so that you can't see in the cib that
> >>> some kind of notification is enabled?
> >> But you cannot see it truthfully in CIB either!

Now you can see in the CIB that notifications are enabled,
but if you have the one script being called notify directly,
or call a bunch of other scripts sequentially/in parallel/in the
background, that's your thing, and not on pacemaker.

Keep it simple on the CIB and Pacemaker side.

If you want to multiplex in the notification script,
do so.

If not, don't.

Pacemaker should not care.


-- 
: Lars Ellenberg
: http://www.LINBIT.com | Your Way to High Availability
: DRBD, Linux-HA  and  Pacemaker support and consulting

DRBD® and LINBIT® are registered trademarks of LINBIT, Austria.