[Pacemaker] colocation issue with master-slave resources

[Patrick H.]

Sent: Mon Nov 28 2011 16:10:01 GMT-0700 (MST)
From: Patrick H. <pacemaker at feystorm.net>
To: The Pacemaker cluster resource manager 
<pacemaker at oss.clusterlabs.org> Andreas Kurz <andreas at hastexo.com>
Subject: Re: [Pacemaker] colocation issue with master-slave resources
> Sent: Mon Nov 28 2011 15:27:10 GMT-0700 (MST)
> From: Andrew Beekhof <andrew at beekhof.net>
> To: The Pacemaker cluster resource manager 
> <pacemaker at oss.clusterlabs.org> Andreas Kurz <andreas at hastexo.com>
> Subject: Re: [Pacemaker] colocation issue with master-slave resources
>> Perhaps try and ordering constraint, I may have also fixed something
>> in this area for 1.1.6 so an upgrade might also help
>>
>> On Tue, Nov 29, 2011 at 1:38 AM, Patrick H.<pacemaker at feystorm.net>  
>> wrote:
>>> Sent: Mon Nov 28 2011 01:31:22 GMT-0700 (MST)
>>> From: Andreas Kurz<andreas at hastexo.com>
>>> To: The Pacemaker cluster resource 
>>> manager<pacemaker at oss.clusterlabs.org>
>>> Subject: Re: [Pacemaker] colocation issue with master-slave resources
>>>
>>> On 11/28/2011 04:51 AM, Patrick H. wrote:
>>>
>>> I'm trying to setup a colocation rule so that a couple of master-slave
>>> resources cant be master unless another resource is running on the same
>>> node, and am getting the exact opposite of what I want. The 
>>> master-slave
>>> resources are getting promoted to master on the node which this other
>>> resource isnt running on.
>>>
>>> In the below example, 'stateful1:Master' and 'stateful2:Master' should
>>> be on the same node 'dummy' is on. It works just fine if I change the
>>> colocation around so that 'dummy' depends on the stateful resources
>>> being master, but I dont want that. I want dummy to be able to run no
>>> matter what, but the stateful resources not be able to become master
>>> without dummy.
>>>
>>>
>>> # crm status
>>> ============
>>> Last updated: Mon Nov 28 03:47:04 2011
>>> Stack: cman
>>> Current DC: devlvs03 - partition with quorum
>>> Version: 1.1.5-5.el6-01e86afaaa6d4a8c4836f68df80ababd6ca3902f
>>> 2 Nodes configured, 2 expected votes
>>> 6 Resources configured.
>>> ============
>>>
>>> Online: [ devlvs04 devlvs03 ]
>>>
>>>   dummy    (ocf::pacemaker:Dummy):    Started devlvs03
>>>   Master/Slave Set: stateful1-ms [stateful1]
>>>       Masters: [ devlvs04 ]
>>>       Slaves: [ devlvs03 ]
>>>   Master/Slave Set: stateful2-ms [stateful2]
>>>       Masters: [ devlvs04 ]
>>>       Slaves: [ devlvs03 ]
>>>
>>>
>>> # crm configure show
>>> node devlvs03 \
>>>      attributes standby="off"
>>> node devlvs04 \
>>>      attributes standby="off"
>>> primitive dummy ocf:pacemaker:Dummy \
>>>      meta target-role="Started"
>>> primitive stateful1 ocf:pacemaker:Stateful
>>> primitive stateful2 ocf:pacemaker:Stateful
>>> ms stateful1-ms stateful1
>>> ms stateful2-ms stateful2
>>> colocation stateful1-colocation inf: stateful1-ms:Master dummy
>>> colocation stateful2-colocation inf: stateful2-ms:Master dummy
>>>
>>> use dummy:Started ... default is to use same role as left resource, and
>>> Dummy will never be in role Master ...
>>>
>>> Regards,
>>> Andreas
>>>
>>> Tried that too (just not the configuration at the time I sent the 
>>> email), no
>>> effect.
>
> Upgraded to 1.1.6 and put in an ordering constraint, still no joy.
>
> # crm status
> ============
> Last updated: Mon Nov 28 23:09:37 2011
> Last change: Mon Nov 28 23:08:34 2011 via cibadmin on devlvs03
> Stack: cman
> Current DC: devlvs03 - partition with quorum
> Version: 1.1.6-1.el6-b379478e0a66af52708f56d0302f50b6f13322bd
> 2 Nodes configured, 2 expected votes
> 5 Resources configured.
> ============
>
> Online: [ devlvs04 devlvs03 ]
>
>  dummy    (ocf::pacemaker:Dummy):    Started devlvs03
>  Master/Slave Set: stateful1-ms [stateful1]
>      Masters: [ devlvs04 ]
>      Slaves: [ devlvs03 ]
>  Master/Slave Set: stateful2-ms [stateful2]
>      Masters: [ devlvs04 ]
>      Slaves: [ devlvs03 ]
>
>
> # crm configure show
> node devlvs03 \
>     attributes standby="off"
> node devlvs04 \
>     attributes standby="off"
> primitive dummy ocf:pacemaker:Dummy \
>     meta target-role="Started"
> primitive stateful1 ocf:pacemaker:Stateful
> primitive stateful2 ocf:pacemaker:Stateful
> ms stateful1-ms stateful1
> ms stateful2-ms stateful2
> colocation stateful1-colocation inf: stateful1-ms:Master dummy:Started
> colocation stateful2-colocation inf: stateful2-ms:Master dummy:Started
> order stateful1-start inf: dummy:start stateful1-ms:promote
> order stateful2-start inf: dummy:start stateful2-ms:promote
> property $id="cib-bootstrap-options" \
>     dc-version="1.1.6-1.el6-b379478e0a66af52708f56d0302f50b6f13322bd" \
>     cluster-infrastructure="cman" \
>     expected-quorum-votes="2" \
>     stonith-enabled="false" \
>     no-quorum-policy="ignore" \
>     last-lrm-refresh="1322450542"
Well there is a really ugly workaround that solves this. If I convert 
'dummy' to a master-slave resource, and just have the slave do nothing. 
It does obey the colocation rule when I tell it to keep the Master roles 
on the same box.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.clusterlabs.org/pipermail/pacemaker/attachments/20111130/44a331eb/attachment.htm>