[Pacemaker] advisory colocation constraint group->service

Wed Oct 29 14:56:13 UTC 2008

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 <beekhof at gmail.com>  
>> 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"/>
>>        
>> -       	  <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  
>>> <andreas.kurz at linbit.com>
> 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
>>>>> Pacemaker at clusterlabs.org
>>>>> 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
>>>> Pacemaker at clusterlabs.org
>>>> http://list.clusterlabs.org/mailman/listinfo/pacemaker
>>
>> _______________________________________________
>> Pacemaker mailing list
>> Pacemaker at clusterlabs.org
>> http://list.clusterlabs.org/mailman/listinfo/pacemaker
>
> _______________________________________________
> Pacemaker mailing list
> Pacemaker at clusterlabs.org
> http://list.clusterlabs.org/mailman/listinfo/pacemaker



