[Pacemaker] Fwd: All resources bounce on failback

[David Morton]

Many thanks Pavel !! Using a value of 0 changes the behavior to the desired,
makes perfect sense when explained in plain terms also !!

I will experiment with some non-0 values, what situations could cause the
order directive not being honored with a 0 value ?

On Tue, Mar 22, 2011 at 8:35 AM, Pavel Levshin <pavel at levshin.spb.ru> wrote:

>
> 21.03.2011 1:39, David Morton:
>
>>
>> order DB_SHARE_FIRST_DEPOT inf: CL_OCFS2_SHARED DEPOT
>> order DB_SHARE_FIRST_ESP_AUDIT inf: CL_OCFS2_SHARED ESP_AUDIT
>>
>>
> Hmm, does not this cause the observed behaviour? Infinite score makes order
> mandatory. It is not simple ordering. It requires to do both actions
> together always. Order is also symmetric by default. Your rules could be
> written in common language as follows:
>
> 1. Always start CL_OCFS2_SHARED then start DEPOT;
> 1a. Always stop DEPOT then stop CL_OCFS2_SHARED;
> 2. Always start CL_OCFS2_SHARED then start ESP_AUDIT;
> 2a. Always stop ESP_AUDIT then stop CL_OCFS2_SHARED;
>
> In your described case, cluster wants to execute 2a. It causes 1a to be
> executed, because CL_OCFS2_SHARED stops. Then the cluster starts DEPOT
> again.
>
> Where this behaviour is useful is not clear to me. Could anyone explain?
>
> I should suggest relaxing your ordering rules to 0: score.
>
>
>
> --
> Pavel Levshin
>
>
> _______________________________________________
> Pacemaker mailing list: Pacemaker at oss.clusterlabs.org
> http://oss.clusterlabs.org/mailman/listinfo/pacemaker
>
> Project Home: http://www.clusterlabs.org
> Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf
> Bugs:
> http://developerbugs.linux-foundation.org/enter_bug.cgi?product=Pacemaker
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.clusterlabs.org/pipermail/pacemaker/attachments/20110322/5a4d5b16/attachment-0003.html>