[Pacemaker] [pacemaker][patch 3/4] Simple changes for "Pacemaker Explained", Chapter 6 CH_Constraints.xml
Tim Serong
tserong at novell.com
Wed Apr 13 02:28:30 EDT 2011
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).
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.
More information about the Pacemaker
mailing list