On Oct 29, 2008, at 2:12 PM, Andreas Kurz wrote:
On Wednesday 29 October 2008 11:28:30 Andrew Beekhof wrote:
On Fri, Oct 24, 2008 at 21:33, Andrew Beekhof <[EMAIL PROTECTED]>
wrote:
Sorry for the delay...
This might be a bug, but I see:
info: native_merge_weights: service_bgp-upc: Breaking dependancy
loop
in the logs, which makes me suspicious about the colocation
constraints (since this shouldn't really happen)
ok, i was correct up to here.
I'm pretty sure you want:
hmm .... not really.
--- cib_group-res-constr.orig.xml 2008-10-29 11:09:47.000000000 +0100
+++ cib_group-res-constr.xml 2008-10-29 11:26:13.000000000 +0100
@@ -265,7 +265,7 @@
<rsc_colocation id="bgp-upc-colocate-with-ip_upc"
from="service_bgp-upc" to="service_ip_upc" score="INFINITY"/>
<rsc_order id="bgp-telekom-after-ip_telekom"
from="service_bgp-telekom" type="after" to="service_ip_telekom"
score="0"/>
<rsc_colocation id="bgp-telekom-colocated-with-ip_telekom"
from="service_bgp-telekom" to="service_ip_telekom" score="INFINITY"/>
- <rsc_colocation id="bgp-upc-colocated-with-bgp_telekom"
from="service_bgp-upc" to="service_bgp-telekom" score="1"
symmetrical="true"/>
^^^^^^^^^^^
My intention for this (^) was to loosely couple them together so
they run
together on the same host. If I decide to stop one of them and
restart it
after a while it should be colocated again with its "partner" ... if
i decide
to migrate only one of the two resources to another node the other
resource
should stay where it is running.
This is not at all related what symmetrical does.
Symmetrical was a work-around for a problem a long time ago and no-one
should be setting it to true.
+ <rsc_colocation id="bgp-upc-colocated-with-bgp_telekom"
from="service_bgp-upc" to="service_bgp-telekom" score="1"/>
<rsc_order id="ospf-dmz-after-ips" from="service_ospf-dmz"
type="after" to="group_routing_ips" score="0"/>
<rsc_colocation id="ospf-dmz-colocate-with-ips"
from="service_ospf-dmz" to="group_routing_ips" score="INFINITY"/>
<rsc_order id="ospf-default-after-ips"
from="service_ospf-default" type="after" to="group_routing_ips"
score="0"/>
@@ -275,8 +275,8 @@
<rsc_colocation id="ipsec-IP-colocate-with-ips"
from="service_ip_IPSEC" to="group_routing_ips" score="1"/>
<rsc_colocation id="mysql-colocate-with-ips" from="mysql"
to="group_routing_ips" score="1"/>
<!-- hmm ... the next two constraints work not as expected -->
- <rsc_colocation id="ips-colocate-with-bgp_telekom"
from="group_routing_ips" to="service_bgp-telekom" score="1"/>
- <rsc_colocation id="ips-colocate-with-bgp_upc"
from="group_routing_ips" to="service_bgp-upc" score="1"/>
no, no ... that's fine ;-) start the group of "other ips" where the
bgp
services are running
Please correct me if I'am wrong but for me it looks like the score
of the
colocation is ignored and always INFINITY.
not quite
I expected the advisory colocation
constraint to not stop an already runing resource to fullfill the
constraint ... is this a misinterpretion?
no
the problem was how non-matches were handled.
matches gained constraint.score (correct), but non-matches always got
set to -INFINITY (wrong).
The following patch makes your scenario behave, I just need to run it
through the regression tests.
diff -r 61b457707d67 pengine/native.c
--- a/pengine/native.c Thu Oct 23 17:05:06 2008 +0200
+++ b/pengine/native.c Wed Oct 29 15:53:02 2008 +0100
@@ -762,9 +762,9 @@ colocation_match(
}
} else if(do_check == FALSE || constraint->score >= INFINITY) {
- crm_debug_2("%s: %s.%s = -INFINITY (%s)", constraint->id, rsc_lh-
>id,
- node->details->uname,
do_check?"failed":"unallocated");
- node->weight = -INFINITY;
+ crm_debug_2("%s: %s.%s -= %d (%s)", constraint->id,
rsc_lh->id,
+ node->details->uname, constraint->score,
do_check?"failed":"unallocated");
+ node->weight = merge_weights(-constraint->score,
node->weight);
}
);
Regards,
Andreas
+ <rsc_colocation id="ips-colocate-with-bgp_telekom"
to="group_routing_ips" from="service_bgp-telekom" score="1"/>
+ <rsc_colocation id="ips-colocate-with-bgp_upc"
to="group_routing_ips" from="service_bgp-upc" score="1"/>
<!-- #################################################### -->
<rsc_order id="stop-bgp-ta-only-after-bgp-upc-start"
from="service_bgp-telekom" action="stop" type="after"
to="service_bgp-upc" to_action="start" symmetrical="false"
score="0"/>
</constraints>
On Wed, Oct 15, 2008 at 18:28, Andreas Kurz
<[EMAIL PROTECTED]>
wrote:
On Wednesday 15 October 2008 11:52:49 Andrew Beekhof wrote:
On Oct 13, 2008, at 5:31 PM, Andreas Kurz wrote:
Hi,
I have another constraints problem with a Heartbeat 2.1.3
installation and I
wonder where's my error in the configuration.
I want to make an advisory colocation of a group of six IPs
with a
service but
when I stop (target_role=stopped) the service, the group is also
stopped:
* default-resource-stickiness 10
* all services are started on the same node
* no location constraints
<rsc_colocation id="ips-colocate-with-srvA"
from="group_ips" to="srvA"
score="1"/>
Is an advisory colocation constraint between a group and a
service
not supported?
It should work.
Can you send me the "cibadmin -Q" output just before you set
target_role=stopped please?
I attached the cib ..... when I stop e.g the resource
"service_ip_upc"
all services that are advisory colocated to this service are also
stopped additionally also the following colocation constraint is
not
working:
<rsc_colocation id="bgp-upc-colocated-with-bgp_telekom"
from="service_bgp-upc"
to="service_bgp-telekom"
score="1" symmetrical="true"/>
If I remove these two colocation constraints
named "ips-colocate-with-bgp_telekom" and "ips-colocate-with-
bgp_upc"
the constraint above works again.
Thx&Regards,
Andreas
_______________________________________________
Pacemaker mailing list
[email protected]
http://list.clusterlabs.org/mailman/listinfo/pacemaker
--
: Andreas Kurz
: LINBIT | Your Way to High Availability
: Tel +43-1-8178292-64, Fax +43-1-8178292-82
:
: http://www.linbit.com
DRBD(R) and LINBIT(R) are registered trademarks of LINBIT, Austria.
This e-mail is solely for use by the intended recipient(s).
Information
contained in this e-mail and its attachments may be confidential,
privileged or copyrighted. If you are not the intended recipient
you are
hereby formally notified that any use, copying, disclosure or
distribution of the contents of this e-mail, in whole or in part,
is
prohibited. Also please notify immediately the sender by return e-
mail
and delete this e-mail from your system. Thank you for your
co-operation.
_______________________________________________
Pacemaker mailing list
[email protected]
http://list.clusterlabs.org/mailman/listinfo/pacemaker
_______________________________________________
Pacemaker mailing list
[email protected]
http://list.clusterlabs.org/mailman/listinfo/pacemaker
_______________________________________________
Pacemaker mailing list
[email protected]
http://list.clusterlabs.org/mailman/listinfo/pacemaker
_______________________________________________
Pacemaker mailing list
[email protected]
http://list.clusterlabs.org/mailman/listinfo/pacemaker
