[Linux-HA] Handling colocation constraints with more than 2 entries

Andreas Kurz andreas.kurz at linbit.com
Tue Oct 5 17:19:57 MDT 2010


On 10/05/2010 06:03 PM, Andrew Beekhof wrote:
> On Tue, Oct 5, 2010 at 3:47 PM, Dejan Muhamedagic <dejanmm at fastmail.fm> wrote:
>> Hi,
>>
>> On Mon, Oct 04, 2010 at 10:36:21PM +0200, Andreas Kurz wrote:
>>> Hello,
>>>
>>> On 10/04/2010 05:36 PM, Dejan Muhamedagic wrote:
>>>> Hi,
>>>>
>>>> On Mon, Oct 04, 2010 at 04:01:50PM +0100, Matthew Richardson wrote:
>>>> I've been playing with pacemaker for a while now, and have recently
>>>> seena  user stung by an issue I had when I first started - namely that
>>>> colocation constraints are limited to 2 entries, unless sets are used.
>>>>
>>>> Thus:
>>>>
>>>> colocation ok inf: A B
>>>>
>>>> is allowed (obviously!)
>>>>
>>>> colocation sets_ok inf: A (B) (C)
>>>>
>>>> is also allowed.
>>>>
>>>> However:
>>>>
>>>> colocation not_ok inf: A B C
>>>>
>>>> isn't valid, though a user might expect it to be equal to the set-based
>>>> contraint.
>>>>
>>>>> Hmm, last time I looked it worked. How do you know that it's not
>>>>> valid?
>>>
>>> I think what Matthew means is:
>>>
>>> colocation ok inf: A B ... produces a colocation constraint A-follows-B
>>>
>>> colocation not_ok inf: A B C ... implicitely configures a resource set
>>> expressing C-follows-B-follows-A, which is exatly the other way round.
>>>
>>> colocation sets_ok inf: A (B) (C) ... configures three resource sets
>>> that behave like (as a lot of user seem to expect from the previous
>>> example) A-follows-B-follows-C
>>
>> Oops.
>>
>>> Dejan, what are your thougts about let the shell "hide" the reversed
>>> behavior of colocation resource sets and let this:
>>>
>>> colocation not_ok inf: A B ( C D ) F G
>>>
>>> ... create:
>>>
>>> <rsc_colocation id="not_ok" score="INFINITY" >
>>>       <resource_set id="collocated-set-1" sequential="true">
>>>         <resource_ref id="B"/>
>>>         <resource_ref id="A"/>
>>>       </resource_set>
>>>       <resource_set id="collocated-set-2" sequential="false">
>>>         <resource_ref id="D"/>
>>>         <resource_ref id="C"/>
>>>       </resource_set>
>>>       <resource_set id="collocated-set-3" sequential="true">
>>>         <resource_ref id="G"/>
>>>         <resource_ref id="F"/>
>>>       </resource_set>
>>> </rsc_colocation>
>>
>> I'm not sure. Either that or to introduce brackets as Andrew
>> suggested once earlier. That would be:
>>
>> colocation not_ok inf: [ A B ] ( C D ) [ F G ]

For the xml-snippet above this ^^^^^ would be ok IMHO

{A-follows-B}-follow-{C and D)} -- C and D with no interdependencies

{C and D}-follow-{F-follows-G}

... please correct me if this is nonsense!

>>
>> or shouldn't it actually be like this:
>>
>> colocation not_ok inf: [ F G ] ( C D ) [ A B ]
> 
> This one is correct

I assume you mean for this xml-code? ... or correct me again ;-)

<rsc_colocation id="not_ok" score="INFINITY" >
       <resource_set id="collocated-set-1" sequential="true">
         <resource_ref id="G"/>
         <resource_ref id="F"/>
       </resource_set>
      <resource_set id="collocated-set-2" sequential="false">
         <resource_ref id="C"/>
         <resource_ref id="D"/>
       </resource_set>
       <resource_set id="collocated-set-3" sequential="true">
         <resource_ref id="B"/>
         <resource_ref id="A"/>
       </resource_set>
</rsc_colocation>

Regards,
Andreas

> 
>>
>>> ... or convince Andrew to change resource sets to _not_ have the same
>>> colocation semantics as groups ... whatever is easier ;-)
>>
>> A good one :)
> 
> Well its not really up to the PE to work around bugs in the shell ;-)
> 
>> Anyway, it's too late to change the semantics as
>> that would change behaviour of the existing clusters.
> 
> Actually the solution is really quite easy.
> 
> 1. Make constraints with > 2 elements and no/insufficient brackets
> produce a warning and require user confirmation.
> There is certainly precedent for things in the shell becoming warnings
> that weren't previously.
> 
> 2. Decide on two types of brackets to use, one for ordered and one for
> unordered.
> 
> 1. gives you backwards computability
> 2. gives us sanity
> 
>>
>> I still find all this confusing.
>>
>> Cheers,
>>
>> Dejan
>>
>>> Regards,
>>> Andreas
>>>
>>>>
>>>>> Thanks,
>>>>
>>>>> Dejan
>>>>
>>>> I would like to suggest 2 potential solutions to this:
>>>>
>>>> 1) (simple) Provide a warning/error message when someone constructs this
>>>> invalid constraint.
>>>>
>>>> 2) (more complex) Translate this constraint to a meaningful set - i.e
>>>> change 'A B C' to 'A (B) (C)'
>>>>
>>>> I'm not sure whether or not the 2nd option makes sense or whether it
>>>> adds some extra level of confusion or uncertainty to its behaviour.
>>>>
>>>> Any comments?  I'm happy to do some work to submit a patch to the shell
>>>> to at least do the basic checking, though this might not be the best
>>>> place (or indeed the best patch) to achieve these, if people think
>>>> they're worthwhile suggestions.
>>>>
>>>> Thanks,
>>>>
>>>> Matthew
>>>>
>>>>>
>>> --
>>> The University of Edinburgh is a charitable body, registered in
>>> Scotland, with registration number SC005336.
>>>>>
>>> _______________________________________________
>>> Linux-HA mailing list
>>> Linux-HA at lists.linux-ha.org
>>> http://lists.linux-ha.org/mailman/listinfo/linux-ha
>>> See also: http://linux-ha.org/ReportingProblems
>>>> _______________________________________________
>>>> Linux-HA mailing list
>>>> Linux-HA at lists.linux-ha.org
>>>> http://lists.linux-ha.org/mailman/listinfo/linux-ha
>>>> See also: http://linux-ha.org/ReportingProblems
>>>
>>> _______________________________________________
>>> Linux-HA mailing list
>>> Linux-HA at lists.linux-ha.org
>>> http://lists.linux-ha.org/mailman/listinfo/linux-ha
>>> See also: http://linux-ha.org/ReportingProblems
>> _______________________________________________
>> Linux-HA mailing list
>> Linux-HA at lists.linux-ha.org
>> http://lists.linux-ha.org/mailman/listinfo/linux-ha
>> See also: http://linux-ha.org/ReportingProblems
>>
> _______________________________________________
> Linux-HA mailing list
> Linux-HA at lists.linux-ha.org
> http://lists.linux-ha.org/mailman/listinfo/linux-ha
> See also: http://linux-ha.org/ReportingProblems




More information about the Linux-HA mailing list