[Pacemaker] ordering cloned resources

Sun Mar 9 07:36:03 EDT 2014

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 <alxgomz at 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 <andrew at beekhof.net>:
>>
>> On 3 Mar 2014, at 3:56 am, Alexandre <alxgomz at 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 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://bugs.clusterlabs.org
>>
>>
>> _______________________________________________
>> 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://bugs.clusterlabs.org
>>