[Pacemaker] colocation rule not obeyed

Tue Nov 30 16:57:53 UTC 2010

Well that fixed the problem. To me that seems weird that when A depends 
on B it doesnt work, but when B depends on A it works fine. But 
whatever, i'll just jot that little note down for future use.

Thanks

Sent: Tue Nov 30 2010 03:07:52 GMT-0700 (Mountain Standard Time)
From: Andrew Beekhof <andrew at beekhof.net>
To: The Pacemaker cluster resource manager <pacemaker at oss.clusterlabs.org>
Subject: Re: [Pacemaker] colocation rule not obeyed
> In general, its better to have the IP (primitive) depend on the clone. eg:
>
>       <rsc_colocation id="co_mysql" with-rsc="ms_mysql"
> with-rsc-role="Master" score="INFINITY" rsc="vip" rsc-role="Started"/>
>
> With that it behaved properly here.
>
> On Mon, Nov 29, 2010 at 4:44 PM, Patrick H. <pacemaker at feystorm.net> wrote:
>   
>> Err, now its attached. Promise :-)
>>
>> -Patrick
>>
>> Sent: Mon Nov 29 2010 08:36:04 GMT-0700 (Mountain Standard Time)
>> From: Patrick H. <pacemaker at feystorm.net>
>> To: The Pacemaker cluster resource manager <pacemaker at oss.clusterlabs.org>
>> Subject: Re: [Pacemaker] colocation rule not obeyed
>>
>> `cibadmin -Q` output is attached
>> From what I can see, it did run a 'start' operation on the 'vip' resource on
>> the devms01 box, and then ran a 'start' 'promote' on 'ms_mysql' on devms02
>> :-/
>>
>> Sent: Mon Nov 29 2010 00:43:48 GMT-0700 (Mountain Standard Time)
>> From: Andrew Beekhof <andrew at beekhof.net>
>> To: The Pacemaker cluster resource manager <pacemaker at oss.clusterlabs.org>
>> Subject: Re: [Pacemaker] colocation rule not obeyed
>>
>> On Mon, Nov 29, 2010 at 6:55 AM, Patrick H. <pacemaker at feystorm.net> wrote:
>>
>>
>> I've got a replicated mysql with vip setup i've been trying to create, and
>> it doesnt seem to be obeying my colocation rule much.
>>
>> Situation:
>> I had shut down corosync on all (3) nodes and verified all associated
>> services were off.
>> I then started it up an all 3 nodes.
>> When it came back up, the VIP was running on node1, while the master mysql
>> service was running on node 2.
>>
>> # crm status
>> ============
>> Last updated: Mon Nov 29 05:51:06 2010
>> Stack: openais
>> Current DC: devms01 - partition with quorum
>> Version: 1.0.9-89bd754939df5150de7cd76835f98fe90851b677
>> 3 Nodes configured, 3 expected votes
>> 2 Resources configured.
>> ============
>>
>> Online: [ devms01 devms02 devms03 ]
>>
>>  vip    (ocf::heartbeat:IPaddr2):       Started devms01
>>  Master/Slave Set: ms_mysql
>>      Masters: [ devms02 ]
>>      Slaves: [ devms01 devms03 ]
>>
>>
>> # crm configure show
>> node devms01 \
>>         attributes standby="off"
>> node devms02 \
>>         attributes standby="off"
>> node devms03
>> primitive mysql ocf:etc:mysql \
>>         params master_host="165.212.101.96" user="mailsafe_rep"
>> pass="replicate" \
>>         op monitor interval="10s" role="Master" \
>>         op monitor interval="60s" role="Slave"
>> primitive vip ocf:heartbeat:IPaddr2 \
>>         params nic="eth0" iflabel="0" ip="165.212.101.96" cidr_netmask="24"
>> broadcast="165.212.101.255" \
>>         meta target-role="Started" is-managed="true"
>> ms ms_mysql mysql \
>>         meta target-role="Master" is-managed="true"
>> colocation co_mysql inf: ms_mysql:Master vip
>> property $id="cib-bootstrap-options" \
>>         dc-version="1.0.9-89bd754939df5150de7cd76835f98fe90851b677" \
>>         cluster-infrastructure="openais" \
>>         expected-quorum-votes="3" \
>>         stonith-enabled="false" \
>>         no-quorum-policy="ignore" \
>>         default-resource-stickiness="INFINITY" \
>>         last-lrm-refresh="1291008843"
>>
>>
>>
>> I dont get it. Why did it decide to just ignore the co_mysql rule?
>>
>>
>> No idea, cibadmin -Q with the cluster in this state?
>>
>> _______________________________________________
>> 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
>>
>>
>> ________________________________
>> _______________________________________________
>> 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
>>
>>
>> _______________________________________________
>> 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
>>
>>
>>     
>
> _______________________________________________
> 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/20101130/5b031aa8/attachment-0002.htm>