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

Andrew Beekhof andrew at beekhof.net
Thu Oct 7 00:26:05 MDT 2010


On Wed, Oct 6, 2010 at 12:34 PM, Dejan Muhamedagic <dejanmm at fastmail.fm> wrote:
> On Tue, Oct 05, 2010 at 06:03:17PM +0200, 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 ]
>> >
>> > or shouldn't it actually be like this:
>> >
>> > colocation not_ok inf: [ F G ] ( C D ) [ A B ]
>>
>> This one is correct
>>
>> >
>> >> ... 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
>
> There's also role change which forces a break in the set. There
> was posted an example like this to the list:
>
> (a) collocation c1 inf: ms-r0:Master fs jboss
>
> or, expressed as a chain of two-resource collocations:
>
> collocation c1_1 inf: jboss fs
> collocation c1_2 inf: fs ms-r0:Master
>
> Now, the resource set would have to be split in two because of
> the role change, but that would also force us to move stuff
> around to preserve semantics:
>
> (b) collocation c1 inf: [ fs jboss ] [ ms-r0:Master ]
>
> Because adjacent resource sets have the same semantics as
> two-resource collocations, right?
>
> The case when the role change is in the middle:
>
> (a) collocation c1 inf: A B:Master C
>
> becomes
>
> (b) collocation c1 inf: [ C ] [ B:Master ] [ A ]
>
> All this strikes me as suboptimal, but I'm not sure what is to be
> done about it.
>
> Basically, users should be able to type the (a) versions and let
> the software handle the rest.
>
> Opinions?

I don't think its a big deal to allow resource's within a set to have
different roles, such that [ C B:Master A ] worked.
Another thing, currently "colocation set-1 inf: rsc_pcmk-1 rsc_pcmk-2
rsc_pcmk-3 rsc_pcmk-4" expands to:

      <rsc_colocation id="set-1" score="INFINITY">
        <resource_set id="set-1-0">
          <resource_ref id="rsc_pcmk-1"/>
          <resource_ref id="rsc_pcmk-2"/>
          <resource_ref id="rsc_pcmk-3"/>
          <resource_ref id="rsc_pcmk-4"/>
        </resource_set>
      </rsc_colocation>

There's no reason why "colocation set-2 inf: [ rsc_pcmk-1 rsc_pcmk-2
rsc_pcmk-3 rsc_pcmk-4 ]" couldn't expand to:

      <rsc_colocation id="set-2" score="INFINITY">
        <resource_set id="set-2-0">
          <resource_ref id="rsc_pcmk-4"/>
          <resource_ref id="rsc_pcmk-3"/>
          <resource_ref id="rsc_pcmk-2"/>
          <resource_ref id="rsc_pcmk-1"/>
        </resource_set>
      </rsc_colocation>

if you preferred.  The shell representation doesn't have to be tightly
coupled to the XML.

The problem here is "just" the change of direction when going from "a
b" to "a b c" in shell syntax - which obviously can't be changed for
compatibility.
But if we're a new syntax with the brackets, then we can provide
whatever semantics we want.
Had "a b c" originally expanded to

...
          <resource_ref id="c"/>
          <resource_ref id="b"/>
          <resource_ref id="a"/>
...

then it wouldn't have been an issue.



More information about the Linux-HA mailing list