[Pacemaker] [pacemaker][patch 3/4] Simple changes for "Pacemaker Explained", Chapter 6 CH_Constraints.xml
Andrew Beekhof
andrew at beekhof.net
Wed Apr 13 02:37:12 EDT 2011
On Wed, Apr 13, 2011 at 8:28 AM, Tim Serong <tserong at novell.com> wrote:
> On 4/12/2011 at 05:48 PM, Andrew Beekhof <andrew at beekhof.net> wrote:
>> Here's an example of the before and after. Thoughts?
>
> Looks pretty good to me. Certainly easier to understand what's
> intended when reading the new version.
>
> Is it worth allowing <colocation_set> and <ordering_set> to have an
> optional role attribute, which would be inherited by all children?
> Or is that just more confusing (too many options not always a good
> thing).
IMHO its more confusing.
Most sets wont set role at all and for the few that do only a fraction
of the resources in the set will typically need it.
So not sure the additional complexity it buys us much other than
questions "do i configure it here or there?".
>
> Tim
>
>>
>> Before:
>>
>> <rsc_colocation id="coloc-set" score="INFINITY">
>> <resource_set id="coloc-set-0">
>> <resource_ref id="dummy2"/>
>> <resource_ref id="dummy3"/>
>> </resource_set>
>> <resource_set id="coloc-set-1" sequential="false" role="Master">
>> <resource_ref id="dummy0"/>
>> <resource_ref id="dummy1"/>
>> </resource_set>
>> </rsc_colocation>
>> <rsc_order id="order-set" score="INFINITY">
>> <resource_set id="order-set-0" role="Master">
>> <resource_ref id="dummy0"/>
>> <resource_ref id="dummy1"/>
>> </resource_set>
>> <resource_set id="order-set-1" sequential="false">
>> <resource_ref id="dummy2"/>
>> <resource_ref id="dummy3"/>
>> </resource_set>
>> </rsc_order>
>>
>>
>>
>> After:
>>
>> <rsc_colocation id="coloc-set" score="INFINITY">
>> <colocation_set id="coloc-set-1" internal-colocation="0">
>> <resource_ref id="dummy0" role="Master"/>
>> <resource_ref id="dummy1" role="Master"/>
>> </colocation_set>
>> <colocation_set id="coloc-set-0" internal-colocation="INFINITY">
>> <resource_ref id="dummy2"/>
>> <resource_ref id="dummy3"/>
>> </colocation_set>
>> </rsc_colocation>
>> <rsc_order id="order-set" kind="Mandatory">
>> <ordering_set id="order-set-0" internal-ordering="Mandatory">
>> <resource_ref id="dummy0" role="Master"/>
>> <resource_ref id="dummy1" role="Master"/>
>> </ordering_set>
>> <ordering_set id="order-set-1" internal-ordering="Optional">
>> <resource_ref id="dummy2"/>
>> <resource_ref id="dummy3"/>
>> </ordering_set>
>> </rsc_order>
>>
>>
>>
>>
>> On Mon, Apr 11, 2011 at 6:02 PM, Andrew Beekhof <andrew at beekhof.net> wrote:
>> > On Mon, Apr 11, 2011 at 3:41 PM, Andrew Beekhof <andrew at beekhof.net> wrote:
>> >> On Mon, Apr 11, 2011 at 2:33 PM, Tim Serong <tserong at novell.com> wrote:
>> >>>> >> > For members within a set (sequential=true), it is true that for a given
>> >>>> >> > member to be active, the previous members must also be active.
>> >>>> >> >
>> >>>> >> > Between sets however, it's the other way around - a given set depends on
>> >>>> >> > the subsequent set.
>> >>>> >>
>> >>>> >> Did I really write it like that? You tested it?
>> >>>> >
>> >>>> > Yup. Well, I tested it (pcmk 1.1.5), so I assume you wrote it like that
>> :)
>> >>>> >
>> >>>> > We want (pardon the ASCII art):
>> >>>> >
>> >>>> > /--> C --\
>> >>>> > G --> F --+---> D ---+--> B --> A
>> >>>> > \- -> E --/
>> >>>> >
>> >>>> > Test is:
>> >>>> >
>> >>>> > # crm configure colocation c inf: F G ( C D E ) A B
>> >>>>
>> >>>> Given the well discussed issues with the shell syntax, I'd prefer to
>> >>>> see the raw xml actually.
>> >>>
>> >>> <constraints>
>> >>> <rsc_colocation id="c" score="INFINITY">
>> >>> <resource_set id="c-0">
>> >>> <resource_ref id="F"/>
>> >>> <resource_ref id="G"/>
>> >>> </resource_set>
>> >>> <resource_set id="c-1" sequential="false">
>> >>> <resource_ref id="C"/>
>> >>> <resource_ref id="D"/>
>> >>> <resource_ref id="E"/>
>> >>> </resource_set>
>> >>> <resource_set id="c-2">
>> >>> <resource_ref id="A"/>
>> >>> <resource_ref id="B"/>
>> >>> </resource_set>
>> >>> </rsc_colocation>
>> >>> </constraints>
>> >>
>> >> So, at least for colocation,
>> >
>> > s/at least//
>> >
>> > I double checked ordering constraints and they work as I think they should.
>> > The basic equivalent to c-2 would be "first=A then=B" which I believe
>> > makes sense.
>> > And if the sets were collapsed, the equivalent is "first=c-0 then=c-1,
>> > first=c-1 then=c-2" which is again the ordering you'd get from a
>> > group.
>> >
>> > So it looks like we "just" need to fix the order in which colocation
>> > sets are processed.
>> > I already know how to use xslt for the conversion, we just need to
>> > finalize the syntax.
>> >
>> >> it looks like we want either the order
>> >> within the set to be the reverse of what it is now.
>> >> Ie.
>> >>
>> >> <resource_set id="c-2">
>> >> <resource_ref id="B"/>
>> >> <resource_ref id="A"/>
>> >> </resource_set>
>> >>
>> >> Or the order of the sets reversed (so as to work like groups).
>> >
>> > On further reflection, I'm pretty sure this is what we want (and what
>> > I had intended originally).
>> >
>> >> Ie.
>> >>
>> >> <resource_set id="c-2">
>> >> <resource_ref id="A"/>
>> >> <resource_ref id="B"/>
>> >> </resource_set>
>> >> <resource_set id="c-1" sequential="false">
>> >> <resource_ref id="C"/>
>> >> <resource_ref id="D"/>
>> >> <resource_ref id="E"/>
>> >> </resource_set>
>> >> <resource_set id="c-0">
>> >> <resource_ref id="F"/>
>> >> <resource_ref id="G"/>
>> >> </resource_set>
>> >>
>> >> Which do people think is going to be more comprehendible?
>> >>
>> >> Since we want new behavior, we should use a new syntax to be able to
>> >> distinguish between the two.
>> >> Which is handy because the existing syntax is clearly challenging.
>> >>
>> >> At a minimum we want s/resource_set/colocation_set/g
>> >>
>> >> Two additional open questions, How to indicate the scores:
>> >> - between the sets
>> >> Keep using the score from the constraint?
>> >> - between resources within a set (sequential is clearly too confusing).
>> >>
>> >> Perhaps with internal_score and external_score attributes for
>> colocation_set's.
>> >> Where the value of external_score on colocation_set N reflects the
>> >> colocation preference with set N-1 (ie. the one above it in xml
>> >> syntax).
>> >>
>> >> And also:
>> >> - how to deal with roles and instances sanely?
>> >>
>> >>
>> >> In pseudo DTD syntax, I think we're looking at something like:
>> >>
>> >> colocation_set ::= id, resource_ref+, internal_score?
>> >
>> > I've changed internal_score to internal-colocation=boolean
>> > Ordering sets will get similar treatment.
>> >
>> > Between the sets, the score/kind from the enclosing constraint should
>> > be sufficient but I'd be happy to hear if anyone can think of
>> > something we cant express properly.
>> >
>> >>
>> >> resource_ref ::= id-ref, action?, role?, instance?
>> >>
>> >> With the whole between sets thing to be still worked out.
>> >>
>> >>>> > # crm resource stop F
>> >>>> > (stops F and G)
>> >>>> > # crm resource start F
>> >>>> > # crm resource stop D
>> >>>> > (stops D, F and G)
>> >>>> > # crm resource start D
>> >>>> > # crm resource stop B
>> >>>> > (stops everything except A)
>> >>>> >
>> >>>> > That shell colocation constraint maps exactly to the (new) XML shown below
>> >>>> > (verified just in case it turned out to be a shell oddity).
>> >>>> >
>> >>>> >> If so, thats just retarded and needs an overhaul.
>> >>>> >
>> >>>> > It is a little... confusing.
>> >>>> >
>> >>>> > Regards,
>> >>>> >
>> >>>> > Tim
>> >>>> >
>> >>>> >> >
>> >>>> >> > The example colocation chain in Pacemaker Explained right now should thus
>> >>>> >> > be changed as follows in order to match the diagram:
>> >>>> >> >
>> >>>> >> > <constraints>
>> >>>> >> > <rsc_colocation id="coloc-1" score="INFINITY" >
>> >>>> >> > <resource_set id="collocated-set-1" sequential="true">
>> >>>> >> > - <resource_ref id="A"/>
>> >>>> >> > - <resource_ref id="B"/>
>> >>>> >> > + <resource_ref id="F"/>
>> >>>> >> > + <resource_ref id="G"/>
>> >>>> >> > </resource_set>
>> >>>> >> > <resource_set id="collocated-set-2" sequential="false">
>> >>>> >> > <resource_ref id="C"/>
>> >>>> >> > <resource_ref id="D"/>
>> >>>> >> > <resource_ref id="E"/>
>> >>>> >> > </resource_set>
>> >>>> >> > <resource_set id="collocated-set-2" sequential="true" role="Master">
>> >>>> >> > - <resource_ref id="F"/>
>> >>>> >> > - <resource_ref id="G"/>
>> >>>> >> > + <resource_ref id="A"/>
>> >>>> >> > + <resource_ref id="B"/>
>> >>>> >> > </resource_set>
>> >>>> >> > </rsc_colocation>
>> >>>> >> > </constraints>
>> >>>> >> >
>> >>>> >> > Regards,
>> >>>> >> >
>> >>>> >> > Tim
>> >>>> >> >
>> >>>> >> >
>> >>>> >> > --
>> >>>> >> > Tim Serong <tserong at novell.com>
>> >>>> >> > Senior Clustering Engineer, OPS Engineering, Novell Inc.
>> >>>> >> >
>> >>>> >> >
>> >>>> >> >
>> >>>> >> >
>> >>>> >> > _______________________________________________
>> >>>> >> > Pacemaker mailing list: Pacemaker at oss.clusterlabs.org
>> >>>> >> > http://oss.clusterlabs.org/mailman/listinfo/pacemaker
>> >>>> >> >
>> >>>> >> > Project Home: http://www.clusterlabs.org
>> >>>> >> > Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf
>> >>>> >> > Bugs:
>> >>>> >> http://developerbugs.linux-foundation.org/enter_bug.cgi?product=Pacemaker
>> >>>> >> >
>> >>>> >>
>> >>>> >
>> >>>> >
>> >>>> >
>> >>>> >
>> >>>> > --
>> >>>> > Tim Serong <tserong at novell.com>
>> >>>> > Senior Clustering Engineer, OPS Engineering, Novell Inc.
>> >>>> >
>> >>>> >
>> >>>> >
>> >>>> > _______________________________________________
>> >>>> > Pacemaker mailing list: Pacemaker at oss.clusterlabs.org
>> >>>> > http://oss.clusterlabs.org/mailman/listinfo/pacemaker
>> >>>> >
>> >>>> > Project Home: http://www.clusterlabs.org
>> >>>> > Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf
>> >>>> > Bugs:
>> >>>> http://developerbugs.linux-foundation.org/enter_bug.cgi?product=Pacemaker
>> >>>> >
>> >>>>
>> >>>
>> >>>
>> >>>
>> >>>
>> >>> --
>> >>> Tim Serong <tserong at novell.com>
>> >>> Senior Clustering Engineer, OPS Engineering, Novell Inc.
>> >>>
>> >>>
>> >>>
>> >>> _______________________________________________
>> >>> Pacemaker mailing list: Pacemaker at oss.clusterlabs.org
>> >>> http://oss.clusterlabs.org/mailman/listinfo/pacemaker
>> >>>
>> >>> Project Home: http://www.clusterlabs.org
>> >>> Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf
>> >>> Bugs:
>> http://developerbugs.linux-foundation.org/enter_bug.cgi?product=Pacemaker
>> >>>
>> >>
>> >
>>
>
>
>
>
> --
> Tim Serong <tserong at novell.com>
> Senior Clustering Engineer, OPS Engineering, Novell Inc.
>
>
>
> _______________________________________________
> Pacemaker mailing list: Pacemaker at oss.clusterlabs.org
> http://oss.clusterlabs.org/mailman/listinfo/pacemaker
>
> Project Home: http://www.clusterlabs.org
> Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf
> Bugs: http://developerbugs.linux-foundation.org/enter_bug.cgi?product=Pacemaker
>
More information about the Pacemaker
mailing list