On Nov 13, 2007, at 11:52 AM, Cousin Marc wrote:
So I get it even less :)
Doesn't it mean that we would just tell heartbeat that we want to
start
applisr0 anywhere where cloner0 is started ?
yes, that's what
<rsc_colocation id="r0_et_applis_stopped" from="applisr0"
to="cloner0"
to_role="stopped" score="-INFINITY"/>
does too.
so i assumed thats what you wanted.
I want it to applisr0 run anywhere where cloner0 is master.
then you only need the second one
<rsc_colocation id="r0_et_applis_master" from="applisr0" to="cloner0"
to_role="master" score="+INFINITY"/>'
The idea behind what I was doing was that I would put -INFINITY
anywhere I
wouldn't want applisr0 to run (stopped and slave), and a small score
(something like 100) where I would rather have it to run (my
preferred node
for applisr0).
sure, in theory that should also work (though you've demonstrated
that
it doesn't and i need to fix that)
If I put +INFINITY as a score for colocation, wouldn't hearbeat
consider that
as long as cloner0 and applisr0 are at the same place, the score is
+INFINITY, wherever it can make both of them run ?
no, your +100 preference would still take effect... it would
determine
which clone instance we decided to colocate it with
This part is completely obscure to me. I thought +INFINITY + 100
would still
be +INFINITY :)
first +100 is applied
then a clone instance is chosen (this choice take into account the
+100 preference)
then +INFINITY takes effect
so yes, in the end you end up with +INFINITY either way.
but along the way, the +100 preference will have the desired effect
Is there somewhere a documentation explaining how all constraints
are taken
into account to determine the final state ? Most of the time, the
result is
OK, but I cannot determine accurately what will happen. I couldn't
find
anything about it in the wiki (maybe I didn't search in the right
place).
BTW, I've created the bug report
There are two related documents at:
http://oss.beekhof.net/~beekhof/heartbeat/docs/
_______________________________________________
Linux-HA mailing list
[email protected]
http://lists.linux-ha.org/mailman/listinfo/linux-ha
See also: http://linux-ha.org/ReportingProblems
