On 4/12/2011 at 05:48 PM, Andrew Beekhof <and...@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 <and...@beekhof.net> wrote: > > On Mon, Apr 11, 2011 at 3:41 PM, Andrew Beekhof <and...@beekhof.net> wrote: > >> On Mon, Apr 11, 2011 at 2:33 PM, Tim Serong <tser...@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 <tser...@novell.com> > >>>> >> > Senior Clustering Engineer, OPS Engineering, Novell Inc. > >>>> >> > > >>>> >> > > >>>> >> > > >>>> >> > > >>>> >> > _______________________________________________ > >>>> >> > Pacemaker mailing list: Pacemaker@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 <tser...@novell.com> > >>>> > Senior Clustering Engineer, OPS Engineering, Novell Inc. > >>>> > > >>>> > > >>>> > > >>>> > _______________________________________________ > >>>> > Pacemaker mailing list: Pacemaker@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 <tser...@novell.com> > >>> Senior Clustering Engineer, OPS Engineering, Novell Inc. > >>> > >>> > >>> > >>> _______________________________________________ > >>> Pacemaker mailing list: Pacemaker@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 <tser...@novell.com> Senior Clustering Engineer, OPS Engineering, Novell Inc. _______________________________________________ Pacemaker mailing list: Pacemaker@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