<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">On 12/03/2015 05:39 PM, Jan Pokorný
wrote:<br>
</div>
<blockquote cite="mid:20151203163949.GC29084@redhat.com" type="cite">
<pre wrap="">On 03/12/15 17:06 +0100, Klaus Wenninger wrote:
</pre>
<blockquote type="cite">
<pre wrap="">On 12/03/2015 04:45 PM, Jan Pokorný wrote:
</pre>
<blockquote type="cite">
<pre wrap="">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!)
</pre>
</blockquote>
<pre wrap="">
Why a dedicated directory so that you can't see in the cib that
some kind of notification is enabled?
</pre>
</blockquote>
<pre wrap="">
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.
</pre>
</blockquote>
But at least you can assure that nothing unknown is run if you see
that it is disabled ;-)<br>
And by e.g. using a path that is proprietary to your cluster you can
prevent that some<br>
rpm is putting scripts to the default location (well not that they
are put there but at<br>
least they wouldn't have any effect).<br>
<blockquote cite="mid:20151203163949.GC29084@redhat.com" type="cite">
<pre wrap="">
</pre>
<blockquote type="cite">
<pre wrap="">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.
</pre>
</blockquote>
<pre wrap="">
Transparency is hard to achieve here directly. Configuration tools could
give you insights on the notification agents in use regardless the method.
</pre>
</blockquote>
If we want more then the notification-agent could have a
monitoring-interface that is<br>
called regularly as with RAs and fencing-RAs. Excuse me if I have
overseen this <br>
consideration already coming up in the thread.<br>
<blockquote cite="mid:20151203163949.GC29084@redhat.com" type="cite">
<pre wrap="">
</pre>
<blockquote type="cite">
<pre wrap="">Or have the path setable with a default like your suggestion and an
on/off parameter...
</pre>
</blockquote>
<pre wrap="">
All up to the consideration.
</pre>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
Developers mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Developers@clusterlabs.org">Developers@clusterlabs.org</a>
<a class="moz-txt-link-freetext" href="http://clusterlabs.org/mailman/listinfo/developers">http://clusterlabs.org/mailman/listinfo/developers</a>
</pre>
</blockquote>
<br>
</body>
</html>