[ClusterLabs Developers] Proposed future feature: multiple notification scripts

[Jan Pokorný]

On 03/12/15 17:06 +0100, Klaus Wenninger wrote:
> On 12/03/2015 04:45 PM, Jan Pokorný wrote:
>> Just thinking out loud, Pacemaker is well adapted to cope with
>> asymmetric/heterogenous nodes (incl. user-assisted optimizations
>> like with non-default "resource-discovery" property of a location
>> contraint, for instance).
>> 
>> Setting notifications universally for all nodes may be desired
>> in some scenarios, but may not be optimal if nodes may diverge,
>> or will for sure:
>> 
>> (1) the script may not be distributed across all the nodes
>>     - or (1b) it is located at the shared storage that will become
>>       available later during cluster life cycle because it is
>>       a subject of cluster service management as well
>> 
>> (2) one intentionally wants to run the notification mechanism
>>     on a subset of nodes
>> 
>> Note also that once you have the responsibility to distribute the
>> script on your own, you can use the same distribution mechanism to
>> share your configuration for this script, as an alternative to using
>> "value" attribute in the above proposal (and again, this way, you
>> are free to have an asymmetric configuration).  There are tons
>> of cases like that and one has to deal with that already (some RAs,
>> file with secret for Corosync, ...).
>> 
>> 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.
>> 
>> --> no configuration needed (or is external to the CIB, or is
>>     interspersed in a non-invasive way there), install and go
>> 
>> --> it has local-only effect, equally as is local the installation
>>     of the respective software utilizing notifications
>>     (and as is local handling of the notifications!)
>> 
> 
> 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!

You can only see a pointer that something could be actually run to
propagate notifications, but without any guarantees that script
actually exist across the nodes, you are at the same level
of oblivion until more investigation performed.

> If we make the drop-in-directory configurable via the cib alternatively
> to the script or even in addition to it this would add transparency.

Transparency is hard to achieve here directly.  Configuration tools could
give you insights on the notification agents in use regardless the method.

> Or have the path setable with a default like your suggestion and an
> on/off parameter...

All up to the consideration.

-- 
Jan (Poki)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <https://lists.clusterlabs.org/pipermail/developers/attachments/20151203/1684c9ac/attachment-0004.sig>