[Pacemaker] The problem that a resource does not move by the monitor error of the clone.

[Andrew Beekhof]

On Thu, Jan 28, 2010 at 12:13 PM, Andrew Beekhof <andrew at beekhof.net> wrote:
> 2010/1/19  <renayama19661014 at ybb.ne.jp>:
>> Hi,
>>
>> Step1) It started in three nodes as follows.
>>
>> [root at srv01 ~]# crm_mon -1
>> ============
>> Last updated: Tue Jan 19 10:36:20 2010
>> Stack: openais
>> Current DC: srv01 - partition with quorum
>> Version: 1.0.7-88fb53f1ea4988cf349ed5db259998eb1ab20b82
>> 3 Nodes configured, 2 expected votes
>> 2 Resources configured.
>> ============
>>
>> Online: [ srv01 srv02 srv03 ]
>>
>>  Resource Group: UMgroup01
>>     UmDummy01  (ocf::heartbeat:Dummy01):       Started srv01
>>  Clone Set: clnUMgroup01
>>     Started: [ srv01 srv03 ]
>>
>>
>> Step2) The monitor error of the clone occurred three times.
>>
>> [root at srv01 ~]# crm_mon -1 -f
>> ============
>> Last updated: Tue Jan 19 10:39:00 2010
>> Stack: openais
>> Current DC: srv01 - partition with quorum
>> Version: 1.0.7-88fb53f1ea4988cf349ed5db259998eb1ab20b82
>> 3 Nodes configured, 2 expected votes
>> 2 Resources configured.
>> ============
>>
>> Online: [ srv01 srv02 srv03 ]
>>
>>  Resource Group: UMgroup01
>>     UmDummy01  (ocf::heartbeat:Dummy01):       Started srv01
>>  Clone Set: clnUMgroup01
>>     Started: [ srv03 ]
>>     Stopped: [ clnUmResource:0 ]
>>
>> Migration summary:
>> * Node srv01:
>>   clnUMdummy01:0: migration-threshold=3 fail-count=3
>> * Node srv02:
>> * Node srv03:
>>
>> Failed actions:
>>    clnUMdummy01:0_monitor_10000 (node=srv01, call=13, rc=7, status=complete): not running
>>
>> Step3)I expected movement to srv03 of the UMgroup01 resource, but do not move.
>
> Agreed (sorry for the delay).
> I'd have expected  clnUMdummy01:0 to be stopped and srv03 to be moved.

Sorry, I meant UMgroup01 not srv03.

>
>>
>> What will be a problem?
>> Or is it a bug?
>
> Looks like a bug.  I'll take a look.
>
>> I attached hb_report and a transition file.

Config issue I'm afraid.

UMgroup01 only prefers the location of clnUMgroup01 with score 1000.
But it prefers its current location with score INFINITY... so
naturally it doesn't move when clnUMgroup01 does.

If resource-stickiness was less than 900 (stickiness -
grp01-1-location + grp01-2-location), it would have moved.