[Linux-HA] Documentation for constraints

[Ragnar Kjørstad]

On Thu, Mar 22, 2007 at 02:05:57PM +0100, Dejan Muhamedagic wrote:
> On Thu, Mar 22, 2007 at 02:21:23AM +0100, Ragnar Kj?rstad wrote:
> > I'm trying to understand the finer details of the constraints, but there
> > are some wholes in the documentation:
> > 
> > I would like to suggest the following changes:
> > 
> > http://wiki.linux-ha.org/v2/dtd1.0/annotated#head-390c0a5ecce666978dab397e20d1575ff366c262
> > 
> > should include more exact information about what implicit rules the
> > group implements.
> > 
> > Is it correct that a group with resources x and y imply rules:
> > <rsc_colocation id="foo" from="y" to="x" score="INFINITY"/>  
> > <rsc_order id="bar" from="x" action="start" type="before" to="y" symmetrical="TRUE"/>
> 
> yes.

I guess this makes more sense in the examples than in the DTD, so I
added this to 
http://wiki.linux-ha.org/ClusterInformationBase/ResourceGroups

> 
> > http://wiki.linux-ha.org/v2/dtd1.0/annotated#head-390c0a5ecce666978dab397e20d1575ff366c262
> > 
> > needs to explain type better. E.g "x start before y" is the same as "y
> > start after x"?

Added this fact to the DTD.

BTW: I just noticed that the DTD is also checked into mercury. So which
is the authoriative version? mercury or wiki?

> > The explanation for symmetrical is also not good enough, because it's
> > not clear what the "reverse" constraint is.
> 
> sounds clear enough to me, but then it's only me :)

The unclear part is that there is 3 things that can be reversed.
"x" vs "y", "start" vs "stop" or "before" vs "after".

I've updated the DTD to specifically state that it is the action and
type that is reversed in the symmetrical rule.


> > Explaining that 
> > <rsc_order id="foo" from="x" action="start" type="before" to="y" symmetrical="TRUE"/>
> > is identical to the following two rules:
> > <rsc_order id="foo" from="x" action="start" type="before" to="y" />
> > <rsc_order id="foo" from="x" action="stop" type="after" to="y" />
> > 
> > would go a long way to explain this.
> 
> right. that's a good way to explain it too. 

Updated the last example on
http://wiki.linux-ha.org/ClusterInformationBase/ResourceGroups with the
non-symmetrical rules equivalent to the symmetrical ones used in the
example.

> incidentally, one
> should s/symetrical/symmetrical/.

Fixed this in the DTD.

> > http://wiki.linux-ha.org/v2/dtd1.0/annotated#head-390c0a5ecce666978dab397e20d1575ff366c262
> > 
> > needs to explain if "x colocated with y" means the same thing as "y
> > colocated with x" or not.
> 
> i believe that it should, but i'm not really sure. anybody?
> 
> > Is it correct that 
> > <rsc_colocation id="foo" from="x" to="y" score="INFINITY"/> 
> > affects the score of x, but not y.
> > 
> > Does that mean that y will be placed first, and x will follow?
> 
> no. it just means that they stay together.
> 
> > What if y is placed on a node where x fails to start, will both x and y
> > be migrated to another node?
> 
> yes. there were some changes though in 2.0.8 to make heartbeat
> more configurable here and to make it possible to stop one
> resource and leave the other in the started state, given that the
> order constraint is right.

Interesting. Any more information?
The changelog includes
  + Support weak and uni-directional collocation constraints (FATE
    300792).
but I see no mention of "weak" or "uni-directional" in the DTD or
anywhere else in the documentation.


> > What is the best practise use of colocation?
> 
> not sure if i understand this. basically, you just use them where
> you need them. hmm, that sounds stupid, but don't see any other
> way to say it :)

I should probably be more explisit:
In an example with resource A(filesystem), B(database), C(webserver)
where A must be started before B before C on the same host. What would
the natural colocation rules be?

I assume one colocation rule between A and B. Does the direction matter?
What about C - does it matter if the rule colocates it with A or B since
they must both be running on the same system anyway?

> > What about colocation rules with -INFINITY score - are they assymetrical
> > as well?
> 
> asymmetrical? they just say that two resources are not to be run
> on the same node. then scores decide what happens.

Well, I assumed that there were some subtile difference between 
"A colocate B score INFINITY" and "B colocate A score INFINITY". But
maybe I was wrong about this?

But my question was if "A colocate B score -INFINITY" is the same as "B
colocate A score -INFINITY".


If the colocation rules are all bi-directional and it doesn't matter
what order it is specified in it's pretty simple, but belive Alan
explained it wasn't that simple.

-- 
Ragnar Kjørstad
Software Engineer
Scali - http://www.scali.com
Scaling the Linux Datacenter