So..., It appears the problem doesn't come from the primitive but for the cloned resource. If I use the primitive instead of the clone in the order constraint (thus deleting the clone and the group) , the second resource of the constraint startup as expected.
Any idea why? Should I upgrade this pretty old version of pacemaker? 2014-03-08 10:36 GMT+01:00 Alexandre <alxg...@gmail.com>: > Hi Andrew, > > I have tried to stop and start the first resource of the ordering > constraint (cln_san), hoping it would trigger a start attemps of the > second resource of the ordering constraint (cln_mailstore). > I tailed the syslog logs on the node where I was expecting the second > resource to start but really nothing appeared in those logs (I grepped > 'pengine as per your suggestion). > > I have done another test, where I changed the first resource of the > ordering constraint with a very simple primitive (lsb resource), and > it worked in this case. > > I am wondering if the issue doesn't come from the rather complicated > first resource. It is a cloned group which contains a primitive > conditional instance attributes... > Are you aware of any specific issue in pacemaker 1.1.7 with this kind > of ressources? > > I will try to simplify the resources by getting rid of the conditional > instance attribute and try again. In the mean time I'd be delighted to > hear about what you guys think about that. > > Regards, Alex. > > 2014-03-07 4:21 GMT+01:00 Andrew Beekhof <and...@beekhof.net>: >> >> On 3 Mar 2014, at 3:56 am, Alexandre <alxg...@gmail.com> wrote: >> >>> Hi, >>> >>> I am setting up a cluster on debian wheezy. >>> I have installed pacemaker using the debian provided packages (so am >>> runing 1.1.7-ee0730e13d124c3d58f00016c3376a1de5323cff). >>> >>> I have roughly 10 nodes, among which some nodes are acting as SAN >>> (exporting block devices using AoE protocol) and others nodes acting >>> as initiators (they are actually mail servers, storing emails on the >>> exported devices). >>> Bellow are the defined resources for those nodes: >>> >>> xml <primitive class="ocf" id="pri_aoe1" provider="heartbeat" >>> type="AoEtarget"> \ >>> <instance_attributes id="pri_aoe1.1-instance_attributes"> \ >>> <rule id="node-sanaoe01" score="1"> \ >>> <expression attribute="#uname" >>> id="expr-node-sanaoe01" operation="eq" value="sanaoe01"/> \ >>> </rule> \ >>> <nvpair id="pri_aoe1.1-instance_attributes-device" >>> name="device" value="/dev/xvdb"/> \ >>> <nvpair id="pri_aoe1.1-instance_attributes-nic" >>> name="nic" value="eth0"/> \ >>> <nvpair id="pri_aoe1.1-instance_attributes-shelf" >>> name="shelf" value="1"/> \ >>> <nvpair id="pri_aoe1.1-instance_attributes-slot" >>> name="slot" value="1"/> \ >>> </instance_attributes> \ >>> <instance_attributes id="pri_aoe2.1-instance_attributes"> \ >>> <rule id="node-sanaoe02" score="2"> \ >>> <expression attribute="#uname" >>> id="expr-node-sanaoe2" operation="eq" value="sanaoe02"/> \ >>> </rule> \ >>> <nvpair id="pri_aoe2.1-instance_attributes-device" >>> name="device" value="/dev/xvdb"/> \ >>> <nvpair id="pri_aoe2.1-instance_attributes-nic" >>> name="nic" value="eth1"/> \ >>> <nvpair id="pri_aoe2.1-instance_attributes-shelf" >>> name="shelf" value="2"/> \ >>> <nvpair id="pri_aoe2.1-instance_attributes-slot" >>> name="slot" value="1"/> \ >>> </instance_attributes> \ >>> </primitive> >>> primitive pri_dovecot lsb:dovecot \ >>> op start interval="0" timeout="20" \ >>> op stop interval="0" timeout="30" \ >>> op monitor interval="5" timeout="10" >>> primitive pri_spamassassin lsb:spamassassin \ >>> op start interval="0" timeout="50" \ >>> op stop interval="0" timeout="60" \ >>> op monitor interval="5" timeout="20" >>> group grp_aoe pri_aoe1 >>> group grp_mailstore pri_dlm pri_clvmd pri_spamassassin pri_dovecot >>> clone cln_mailstore grp_mailstore \ >>> meta ordered="false" interleave="true" clone-max="2" >>> clone cln_san grp_aoe \ >>> meta ordered="true" interleave="true" clone-max="2" >>> >>> As I am in an "opt-in cluster" mode (symmetric-cluster="false"), I >>> have the location constraints bellow for those hosts: >>> >>> location LOC_AOE_ETHERD_1 cln_san inf: sanaoe01 >>> location LOC_AOE_ETHERD_2 cln_san inf: sanaoe02 >>> location LOC_MAIL_STORE_1 cln_mailstore inf: ms01 >>> location LOC_MAIL_STORE_2 cln_mailstore inf: ms02 >>> >>> So far so good. I want to make sure the initiators won't try to search >>> for exported devices before the targets actually exported them. To do >>> so, I though I could use the following ordering constraint: >>> >>> order ORD_SAN_MAILSTORE inf: cln_san cln_mailstore >>> >>> Unfortunately if I add this constraint the clone Set "cln_mailstore" >>> never starts (or even stops if started when I add the constraint). >>> >>> Is there something wrong with this ordering rule? >>> Where can i find informations on what's going on? >> >> No errors in the logs? >> If you grep for 'pengine' does it want to start them or just leave them >> stopped? >> >>> >>> _______________________________________________ >>> 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://bugs.clusterlabs.org >> >> >> _______________________________________________ >> 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://bugs.clusterlabs.org >> _______________________________________________ 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://bugs.clusterlabs.org