[Pacemaker] Location score inf doesn't mean 'must'

[Dejan Muhamedagic]

Hi,

On Thu, Jun 16, 2011 at 01:38:32PM +0200, Pawel Warowny wrote:
> Hi
> 
> Because my cluster behaves strangely (which i described in post 'start
> order after manual migration') I created new cluster only for testing.
> 
> It consists of two nodes: bolek and lolek
> 
> Configuration is very simple:
> At first starting 4 clone resources (res1, res2, res3, res4) one
> after another. After this starting the last single resource
> (i-should-start-last) which can move between nodes.
> 
> The first problem: I created location with score INF for resource
> i-should-start-last so that resource MUST run on node 'bolek':
> 
> location loc_i-should-start-last i-should-start-last inf: bolek
> 
> then I forced node bolek into standby:
> crm node standby bolek
> 
> After this, resource i-should-start-last started on node lolek. Why?
> 
> There is in documentation:
> Negative values indicate the resource can not run on this node. Values of +/-
> INFINITY change "can" to "must".
> 
> So if the resource must run on node bolek, why it is running on node
> lolek?

Because bolek is not available. A negative preference value (any
negative value) is going to prevent a resource to run on a node.
Perhaps the documentation needs an update.

> Apart of this, why node lolek before starting i-must-start-last
> resource stopping and starting all other resources (see logs below).
> 
> My configuration:
> 
> primitive res1 ocf:pacemaker:Dummy
> primitive res2 ocf:pacemaker:Dummy
> primitive res3 ocf:pacemaker:Dummy
> primitive res4 ocf:pacemaker:Dummy
> primitive i-should-start-last ocf:pacemaker:Dummy
> 
> clone res1-clone res1
> clone res2-clone res2
> clone res3-clone res3
> clone res4-clone res4
> 
> location loc_i-should-start-last i-should-start-last inf: bolek
> 
> colocation res1_with_res2 inf: res2-clone res1-clone
> colocation res2_with_res3 inf: res3-clone res2-clone
> colocation res3_with_res4 inf: res4-clone res3-clone
> colocation res4_with_i-should-start-last 1000: i-should-start-last res4-clone
> 
> order res1_before_res2 inf: res1-clone res2-clone
> order res2_before_res3 inf: res2-clone res3-clone
> order res3_before_res4 inf: res3-clone res4-clone
> order res4_before_i-should-start-last inf: res4-clone i-should-start-last
> 
> After standby node bolek i've got in logs:
> 
> Logs from bolek:
> 
> Jun 16 13:04:40 bolek lrmd: [1743]: info: rsc:i-should-start-last:337: stop
> Jun 16 13:04:40 bolek lrmd: [1743]: info: rsc:res4:1:338: stop
> Jun 16 13:04:40 bolek lrmd: [1743]: info: rsc:res3:0:339: stop
> Jun 16 13:04:40 bolek lrmd: [1743]: info: rsc:res2:0:340: stop
> Jun 16 13:04:40 bolek lrmd: [1743]: info: rsc:res1:0:341: stop
> 
> Logs from lolek:
> 
> Jun 16 13:04:06 lolek lrmd: [1868]: info: rsc:res4:0:256: stop
> Jun 16 13:04:07 lolek lrmd: [1868]: info: rsc:res3:1:257: stop
> Jun 16 13:04:07 lolek lrmd: [1868]: info: rsc:res2:1:258: stop
> Jun 16 13:04:07 lolek lrmd: [1868]: info: rsc:res2:1:259: start
> Jun 16 13:04:07 lolek lrmd: [1868]: info: rsc:res3:1:260: start
> Jun 16 13:04:07 lolek lrmd: [1868]: info: rsc:res4:0:261: start
> Jun 16 13:04:07 lolek lrmd: [1868]: info: rsc:i-should-start-last:262: start

I think that there was such a problem reported in the past.
Don't know if it has been fixed and for what version. Perhaps
somebody else on this list can recall the outcome.

Thanks,

Dejan

> Best regards
> 
> -- 
> Pawel Warowny



> _______________________________________________
> 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