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 <pa...@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@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 >
_______________________________________________ Pacemaker mailing list: Pacemaker@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
