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
