On Mon, May 09, 2011 at 11:07:37AM +0200, Andrew Beekhof wrote: > On Fri, May 6, 2011 at 12:29 PM, Dejan Muhamedagic <deja...@fastmail.fm> > wrote: > > On Fri, May 06, 2011 at 09:47:29AM +0200, Andrew Beekhof wrote: > >> On Thu, May 5, 2011 at 5:20 PM, Dejan Muhamedagic <deja...@fastmail.fm> > >> wrote: > >> > On Thu, May 05, 2011 at 12:02:01PM +0200, Andrew Beekhof wrote: > >> >> On Thu, May 5, 2011 at 11:37 AM, Dejan Muhamedagic > >> >> <deja...@fastmail.fm> wrote: > >> >> > On Thu, May 05, 2011 at 09:07:05AM +0200, Andrew Beekhof wrote: > >> >> >> On Wed, May 4, 2011 at 7:15 PM, Dejan Muhamedagic > >> >> >> <deja...@fastmail.fm> wrote: > >> >> >> > Hi, > >> >> >> > > >> >> >> > On Wed, May 04, 2011 at 12:49:03PM +0200, Andrew Beekhof wrote: > >> >> >> >> Tick tock. I'm going to push this soon unless someone raises an > >> >> >> >> objection RSN. > >> >> >> >> > >> >> >> >> On Fri, Apr 15, 2011 at 4:55 PM, Andrew Beekhof > >> >> >> >> <and...@beekhof.net> wrote: > >> >> >> >> > On Fri, Apr 15, 2011 at 3:00 PM, Lars Marowsky-Bree > >> >> >> >> > <l...@novell.com> wrote: > >> >> >> >> >> On 2011-04-13T08:37:12, Andrew Beekhof <and...@beekhof.net> > >> >> >> >> >> wrote: > >> >> >> >> >> > >> >> >> >> >>> >> 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: > >> >> >> >> >> > >> >> >> >> >> So I am understanding this properly - we're getting rid of the > >> >> >> >> >> "sequential" attribute, yes? > >> >> >> >> > > >> >> >> >> > Absolutely. > >> >> >> > > >> >> >> > So, the internal-collocation replaces the sequential attribute? > >> >> >> > >> >> >> Yes. > >> >> >> > >> >> >> > What are the possible and/or meaningfull values for > >> >> >> > internal-collocation? It looks like that would be 0 or INFINITY > >> >> >> > only, which would translate to old sequential false and true, > >> >> >> > right? > >> >> >> > >> >> >> No. > >> >> >> > >> >> >> <choice> > >> >> >> <data type="integer"/> > >> >> >> <value>INFINITY</value> > >> >> >> <value>+INFINITY</value> > >> >> >> <value>-INFINITY</value> > >> >> >> </choice> > >> >> > > >> >> > I saw that, but wonder what makes sense in this context. What's > >> >> > the difference between values 0, INF, 50, -50, 100? Are all those > >> >> > necessary? > >> >> > >> >> Just as necessary as for colocation constraints not involving sets. > >> >> You're setting up the colocation score between elements of the set. > >> > > >> > OK. > >> > > >> >> >> > Looking at the schema, the ordering constraint lost score > >> >> >> > >> >> >> Score was being mapped to "kind" inside the PE anyway. > >> >> >> > >> >> >> > and is > >> >> >> > using only the kind attribute which can have one of: > >> >> >> > > >> >> >> > <value>None</value> > >> >> >> > <value>Optional</value> > >> >> >> > <value>Mandatory</value> > >> >> >> > <value>Serialize</value> > >> >> >> > > >> >> >> > But then, the "kind" attribute is optional. If missing, how's > >> >> >> > that different from value None? > >> >> >> > >> >> >> If its missing you get the default. Which IIRC is Mandatory not > >> >> >> None. > >> >> >> > >> >> >> > What does Serialize mean? (in orders) > >> >> >> > >> >> >> Same as it did before, this is not new. > >> >> >> > >> >> >> > What does score-attribute-mangle mean? (in collocations) > >> >> >> > >> >> >> As above. Not new. > >> >> > > >> >> > Where are these two documented? Couldn't find anything in the > >> >> > docs. > >> >> > >> >> Looks to be just an alias for XML_RULE_ATTR_SCORE_ATTRIBUTE dating back > >> >> to 2005. > >> >> So there is probably a reason I didn't document it. > >> > > >> > So, it's obsolete then? The crm shell actually never supported > >> > it :-| And I can't recall that I've ever seen it in a > >> > configuration. > >> > > >> >> Serialize is newer. Its like optional but for a set - no member will > >> >> start or stop at the same time as another. > >> > > >> > OK. > >> > > >> >> >> > I think that it'd be good to clarify the shell syntax before > >> >> >> > applying these changes. > >> > >> Actually I'm going to flip-flop here... there's really no need for this. > >> Until the shell understands the new syntax, it will just show xml right? > > > > Right. But in my experience trying things out in shell syntax > > sometimes reveals design shortcomings. That was so with the > > resource sets. > > > > Going back to the example you've shown earlier in this thread ... > > > > Before: > > > > collocation c inf: ( dummy0:Master dummy1:Master ) dummy2 dummy3 > > order o Mandatory: dummy0:promote dummy1:promote ( dummy2 dummy3 ) > > > > After(1): > > > > collocation_set c inf: 0:[dummy0:Master dummy1:Master] inf:[dummy2 dummy3] > > order_set o Mandatory: Mandatory:[dummy0:promote dummy1:promote] > > Optional:[dummy2 dummy3] > > > > After(2): > > > > collocation_set c inf: 0:[dummy0:Master dummy1:Master] dummy2 dummy3 > > order_set o Mandatory: dummy0:promote dummy1:promote Optional:[dummy2 > > dummy3] > > > > The second version removes redundant specification, i.e. for the > > sets which have the same kind/score as the constraint. > > > > Would this kind of XML be possible: > > Is the schema that hard to read?
What I wrote below was based on the schema which I attached to the message (don't know if you noticed it). > No, not possible since the same concepts can be expressed without > suppressing the colocation_set elements. I am not sure I follow. Do you mean that there could be two different XML with exactly the same semantics (i.e. the one with and the other without the colocation_set wrapper)? Why would that be a problem? > > <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> > > <resource_ref id="dummy2"/> > > <resource_ref id="dummy3"/> > > </rsc_colocation> > > Also, this example makes no sense. > How do you colocate dummy2 with dummy0 and dummy1 if 0 and 1 are on > different machines? That's your example, just rewritten with the last two resources without the wrapper which repeats what's already been specified in the outer rsc_colocation element. I didn't pay attention to the meaning at all. > > <rsc_order id="order-set" kind="Mandatory"> > > <resource_ref id="dummy0" action="promote"/> > > <resource_ref id="dummy1" action="promote"/> > > <ordering_set id="order-set-1" internal-ordering="Optional"> > > <resource_ref id="dummy2"/> > > <resource_ref id="dummy3"/> > > </ordering_set> > > </rsc_order> > > > > For instance, that way we won't have single resource sets which > > look silly. > > Thats for the shell to deal with. Sorry. > If you want to omit the delimiters for a single set, or the first one, > or the last one, or the one in the middle - go for it. > But that's got nothing to do with the XML. OK. Though I wish I could understand why is that impossible to code in such a way in XML. I mean, semantically it is the same thing, right? It's just that the latter version has a bit less scaffolding. > >> Also, the changes wont be in a release until 1.1.7 and it will take a > >> while to enter common usage. > >> So I think you have time. > > > > OK. > > > >> > I'm going to try to do something today and tomorrow, but next > >> > week I'll be away. So, if you're in a hurry, go ahead with the > >> > changes. > >> > > >> > Just two more notes regarding the language: > >> > > >> > There's "colocation_set/internal-colocation" and > >> > "ordering_set/internal-ordering". They sound different. Should > >> > the order stuff be "order_set/internal-order"? I'm not partial > >> > to any and furthermore not a native speaker, so I'll leave that > >> > to you and others who are more intimate with english. > >> > >> As an engineer my grasp on english can be tenuous at times, but > >> "internal-order" feels wrong. > > > > How about internal-score for both? I mean, we already know what > > kind of constraint it is. > > Score does not make sense for ordering constraints. > Since we're already removing it from the non-set version, it doesn't > make sense to add it back here. Ah, forgot that again. OK, then internal-score and internal-kind? Or just "score" and "kind"? The thing is, for instance in the rsc_colocation element, there's the "score" attribute specifying the same kind of thing as the "internal-colocation" attribute in the colocation_set element. That sounds confusing to me. And how about "collocation" instead of "colocation"? At least my dictionaries prefer the former spelling. Cheers, Dejan > >> > Are we going to name the new stuff differently in shell? Such as > >> > collocation_set and order(ing)_set? Though I don't like these in > >> > particular, because they are going to be the only ones with '_' > >> > in its names, > >> > >> I was using '-', but then I noticed all the other tag names used '_'. > >> Then I remembered deciding at one point to use '_' for tag names > >> (partly because changing them is hard) and '-' for attributes. > >> > >> Having said that, the tokens used by the shell are not required to > >> match those in the xml. > >> Though it may require more work when translating between xml and shell > >> syntax. > > > > Yes, I know that, and I was actually asking about the names in > > the shell because I cannot think of anything better than > > order_set or collocation_set. > > > >> Remember to check the validate-with field though - to see which > >> version of the syntax the cluster is currently using. > > > > Right. > > > > Thanks, > > > > Dejan > > > >> > but there seems to be no way around it. Any better > >> > suggestions? > >> > > >> > Thanks, > >> > > >> > Dejan > >> > > >> > _______________________________________________ > >> > 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 > > > > _______________________________________________ > > 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 _______________________________________________ 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
