On Wed, Apr 13, 2011 at 8:28 AM, Tim Serong <tser...@novell.com> wrote: > 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).
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 <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 > _______________________________________________ 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