[Pacemaker] Shouldn't colocation -inf: be mandatory?

[Vadym Chepkov]

On Jun 15, 2010, at 3:55 PM, Dejan Muhamedagic wrote:

> On Tue, Jun 15, 2010 at 03:41:17PM -0400, Vadym Chepkov wrote:
>> 
>> On Jun 15, 2010, at 3:36 PM, Dejan Muhamedagic wrote:
>> 
>>> Hi,
>>> 
>>> On Tue, Jun 15, 2010 at 08:45:37AM -0400, Vadym Chepkov wrote:
>>>> 
>>>> On Jun 15, 2010, at 6:14 AM, Dejan Muhamedagic wrote:
>>>> 
>>>>> Hi,
>>>>> 
>>>>> On Tue, Jun 15, 2010 at 10:57:47AM +0200, Andrew Beekhof wrote:
>>>>>> On Tue, Jun 15, 2010 at 10:23 AM, Andreas Kurz <andreas.kurz at linbit.com> wrote:
>>>>>>> On Tuesday 15 June 2010 08:40:58 Andrew Beekhof wrote:
>>>>>>>> On Mon, Jun 14, 2010 at 4:22 PM, Vadym Chepkov <vchepkov at gmail.com> wrote:
>>>>>>>>> On Jun 7, 2010, at 8:04 AM, Vadym Chepkov wrote:
>>>>>>>>>> I filed bug 2435, glad to hear "it's not me"
>>>>>>>>> 
>>>>>>>>> Andrew closed this bug
>>>>>>>>> (http://developerbugs.linux-foundation.org/show_bug.cgi?id=2435) as
>>>>>>>>> resolved, but I respectfully disagree.
>>>>>>>>> 
>>>>>>>>> I will try to explain a problem again in this list.
>>>>>>>>> 
>>>>>>>>> lets assume you want to have several resources running on the same node.
>>>>>>>>> They are independent, so if one is going down, others shouldn't be
>>>>>>>>> stopped. You would do this by using a resource set, like this:
>>>>>>>>> 
>>>>>>>>> primitive dummy1 ocf:pacemaker:Dummy
>>>>>>>>> primitive dummy2 ocf:pacemaker:Dummy
>>>>>>>>> primitive dummy3 ocf:pacemaker:Dummy
>>>>>>>>> colocation together inf: ( dummy1 dummy2 dummy3 )
>>>>>>>>> 
>>>>>>>>> and I expect them to run on the same host, but they are not and I
>>>>>>>>> attached hb_report to the case to prove it.
>>>>>>>>> 
>>>>>>>>> Andrew closed it with the comment "Thats because you have
>>>>>>>>> sequential="false" for the colocation set." But sequential="false" means
>>>>>>>>> doesn't matter what order do they start.
>>>>>>>> 
>>>>>>>> No.  Thats not what it means.
>>>>>>>> And I believe I should know.
>>>>>>>> 
>>>>>>>> It means that the members of the set are NOT collocated with each
>>>>>>>> other, only with any preceding set.
>>>>>>> 
>>>>>>> Just for clarification:
>>>>>>> 
>>>>>>> colocation together inf: ( dummy1 dummy2 dummy3 ) dummy4
>>>>>>> 
>>>>>>> .... is a shortcut for:
>>>>>>> 
>>>>>>> colocation together1 inf: dummy4 dummy1
>>>>>>> colocation together1 inf: dummy4 dummy2
>>>>>>> colocation together1 inf: dummy4 dummy3
>>>>>>> 
>>>>>>> ... is that correct?
>>>>>> 
>>>>>> Only if sequential != false.
>>>>> 
>>>>> You wanted to say "sequential == false"?
>>>>> 
>>>>>> For some reason the shell appears to be setting that by default.
>>>>> 
>>>>> This is sequential == false:
>>>>> 
>>>>> colocation together inf: ( dummy1 dummy2 dummy3 ) dummy4
>>>>> 
>>>>> This is sequential == true:
>>>>> 
>>>>> colocation together inf: dummy1 dummy2 dummy3 dummy4
>>>>> 
>>>>> Thanks,
>>>>> 
>>>>> Dejan
>>>> 
>>>> 
>>>> I guess colocation syntax needs to be expanded to allow something like this
>>>> 
>>>> colocation only-one -inf: (dummy1 dummy2 sequential="true")
>>>> 
>>>> colocation together 5000: (dummy1 dummy2 sequential="true")
>>> 
>>> How's this different from a regular constraint?
>>> 
>> 
>> 
>> Because it does not create a resource set with two resources
>> and if you put it in parentheses, it creates set with sequential="false"
> 
> What I meant was what is the difference between these two:
> 
> <rsc_colocation id="c1" rsc="p1" score="500" with-rsc="p2"/>
> 
> <rsc_colocation id="c1" score="500">
> <resource_set id="c1-0">
>  <resource_ref id="p1"/>
>  <resource_ref id="p2"/>
> </resource_set>
> </rsc_colocation>
> 

I take it there is no difference for the positive score, 
it just looks like former looks like there is a dependency of p1 on p2.

But there is a definite difference with a negative score, 

if you have something like this

colocation only-one -inf: dummy1 dummy2

so you don't want to have them to run on the same host ever.
and the host with dummy2 goes down.
Instead of just not starting dummy2 anywhere it will kill dummy1 too and start dummy2 on the surviving host.
That's an outage and not what I wanted to achieve.

Vadym