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

[Andrew Beekhof]

On Tue, Jun 15, 2010 at 2:57 PM, Vadym Chepkov <vchepkov at gmail.com> wrote:
>
> On Jun 15, 2010, at 7:50 AM, Andrew Beekhof wrote:
>
>> On Tue, Jun 15, 2010 at 1:38 PM, Vadym Chepkov <vchepkov at gmail.com> wrote:
>>>
>>> On Jun 15, 2010, at 4:57 AM, 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.
>>>> For some reason the shell appears to be setting that by default.
>>>>
>>>>>
>>>>> To pick up Vadym's Question:
>>>>>
>>>>> *  what would be the correct syntax to say "run-together-but-dont-care-if-one-
>>>>> dies-or-is-not-runable"?
>>>>
>>>> Choose a score < inf, just like regular colocation constraints.
>>>
>>> Ah, ok, thanks, I guess in my mind anything less then inf was "advisory".
>>
>> They are.
>>
>> Advisory is the only way to deal with the
>> "but-dont-care-if-one-dies-or-is-not-runable" part.
>>
>>> As long as I keep it above any resource-stickiness it should be in fact mandatory, right?
>>> Or something else needs to be taken to consideration?
>
> what about this part? what do I need to do to prevent them from running on different nodes for sure?

You can't have it both ways.
Either they have to run on the same node or they can remain active
when one or more die.

Although you could do:

d1 ( d2 d3 d4 )

That would almost get what you want, unless d1 dies.

>
>
>>>
>>> On a side note, I was trying to figure out how to make a set from two resources, so I just added a proper xml and checked what crm shell say about it. And it shows it like this:
>>>
>>> colocation together 5000: _rsc_set_ dummy1 dummy2
>>
>> Strange.  Dejan?
>>
>>>
>>> Who knew? I didn't see it anywhere in documentation.
>>>
>>> Anyway, just so I get it right, what would be the opposite constraint (which is what this thread started from)
>>> If I want to have same dummy1, dummy2, dummy3 resources, but I don't want any of them ever to run simultaneously on the same host. What wold be the proper anti-colocation constraint for this configuration?
>>
>> Score = -inf, plus the patch, plus sequential = true (or unset).
>> Not sure how that looks in shell syntax though.
>
> My guess is for two resources it's
> colocation onlyone -inf: _rsc_set_ dummy1 dummy2

I certainly hope not.

> and a patch. Would you include it in 1.0.9, by any chance?

If it lands in the next few days.