[ClusterLabs Developers] Proposed future feature: multiple notification scripts

[Andrew Beekhof]

> On 7 Dec 2015, at 8:31 PM, Lars Ellenberg <Lars.Ellenberg at linbit.com> wrote:
> 
> 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.

Thats what we’re explicitly trying to avoid.

Three main reasons:
- each script will probably have a different destination
- there’s no way to tell if the list of scripts is consistent across nodes
- too easy for scripts to screw things up for those that come after (taking too long, consuming resources, etc)

Plus the joy of dealing with people breaking it ;-)

Originally I expected that it would be rare that there would ever need to be more than one script called.
But its becoming increasingly clear that this wont be the case in some environments, eg. openstack
So the implementation needs to be adjusted.

> 
> 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.
> 
> _______________________________________________
> Developers mailing list
> Developers at clusterlabs.org
> http://clusterlabs.org/mailman/listinfo/developers