[ClusterLabs Developers] Proposed future feature: multiple notification scripts

[Klaus Wenninger]

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:
>>> 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.
But at least you can assure that nothing unknown is run if you see that
it is disabled ;-)
And by e.g. using a path that is proprietary to your cluster you can
prevent that some
rpm is putting scripts to the default location (well not that they are
put there but at
least they wouldn't have any effect).
>> 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.
If we want more then the notification-agent could have a
monitoring-interface that is
called regularly as with RAs and fencing-RAs. Excuse me if I have
overseen this
consideration already coming up in the thread.
>> Or have the path setable with a default like your suggestion and an
>> on/off parameter...
> All up to the consideration.
>
>
>
> _______________________________________________
> Developers mailing list
> Developers at clusterlabs.org
> http://clusterlabs.org/mailman/listinfo/developers

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.clusterlabs.org/pipermail/developers/attachments/20151203/df3975fb/attachment-0002.html>