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 >> > _______________________________________________ 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