[ClusterLabs] Pacemaker 1.1.15 - Release Candidate 4

[Klaus Wenninger]

Sorry, I hadn't seen that you had replied (don't know why maybe I just
had derived that from the time ;-) ).
But I guess what I've written doesn't really contradict your answer ...
Although it might make look us a little uncoordinated - anyway sorry
again...

Klaus

On 06/12/2016 04:50 PM, Ken Gaillot wrote:
> On 06/12/2016 07:28 AM, Ferenc Wágner wrote:
>> Ken Gaillot <kgaillot at redhat.com> writes:
>>
>>> With this release candidate, we now provide three sample alert scripts
>>> to use with the new alerts feature, installed in the
>>> /usr/share/pacemaker/alerts directory.
>> Hi,
>>
>> Is there a real reason to name these scripts *.sample?  Sure, they are
>> samples, but they are also usable as-is, aren't they?
> Almost as-is -- copy them somewhere, rename them without ".sample", and
> mark them executable.
>
> After some discussion, we decided that this feature is not mature enough
> yet to provide the scripts for direct use. After we get some experience
> with how users actually use the feature and the sample scripts, we can
> gain more confidence in recommending them generally. Until then, we
> recommend that people examine the script source and edit it to suit
> their needs before using it.
>
> That said, I think the SNMP script in particular is quite useful.
>
> The log-to-file script is more a proof-of-concept that people can use as
> a template. The SMTP script may be useful, but probably paired with some
> custom software handling the recipient address, to avoid flooding a real
> person's mailbox when a cluster is active.
>
>>> The ./configure script has a new "--with-configdir" option.
>> This greatly simplifies packaging, thanks much!
>>
>> Speaking about packaging: are the alert scripts run by remote Pacemaker
>> nodes?  I couldn't find described which nodes run the alert scripts.
>> From the mailing list discussions I recall they are run by each node,
>> but this would be useful to spell out in the documentation, I think.
> Good point. Alert scripts are run only on cluster nodes, but they
> include remote node events. I'll make sure the documentation mentions that.
>
>> Similarly for the alert guarrantees: I recall there's no such thing, but
>> one could also think they are parts of transactions, thus having recovery
>> behavior similar to the resource operations.  Hmm... wouldn't such
>> design actually make sense?
> We didn't want to make any cluster operation depend on alert script
> success. The only thing we can guarantee is that the cluster will try to
> call the alert script for each event. But if the system is going
> haywire, for example, we may be unable to spawn a new process due to
> some resource exhaustion, and of course the script itself may have problems.
>
> Also, we wanted to minimize the script interface, and keep it
> backward-compatible with crm_mon external scripts. We didn't want to add
> an OCF-style layer of meta-data, actions and return codes, instead
> keeping it as simple as possible for anyone writing one.
>
> Since it's a brand new feature, we definitely want feedback on all
> aspects once it's in actual use. If alert script failures turns out to
> be a big issue, I could see maybe reporting them in cluster status (and
> allowing that to be cleaned up).
>
> _______________________________________________
> Users mailing list: Users at clusterlabs.org
> http://clusterlabs.org/mailman/listinfo/users
>
> Project Home: http://www.clusterlabs.org
> Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf
> Bugs: http://bugs.clusterlabs.org