[Pacemaker] [pacemaker][patch 3/4] Simple changes for "Pacemaker Explained", Chapter 6 CH_Constraints.xml

Dejan Muhamedagic dejanmm at fastmail.fm
Tue May 17 10:26:29 UTC 2011 

On Mon, May 09, 2011 at 11:07:37AM +0200, Andrew Beekhof wrote:
> On Fri, May 6, 2011 at 12:29 PM, Dejan Muhamedagic <dejanmm at 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 <dejanmm at 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 <dejanmm at 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 <dejanmm at 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 <andrew at beekhof.net> wrote:
> >> >> >> >> > On Fri, Apr 15, 2011 at 3:00 PM, Lars Marowsky-Bree <lmb at novell.com> wrote:
> >> >> >> >> >> On 2011-04-13T08:37:12, Andrew Beekhof <andrew at 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 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
> >> >
> >>
> >> _______________________________________________
> >> 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
> >
> > _______________________________________________
> > 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
> >
> 
> _______________________________________________
> 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

More information about the Pacemaker mailing list