[Pacemaker] [pacemaker][patch 3/4] Simple changes for "Pacemaker Explained", Chapter 6 CH_Constraints.xml
Andrew Beekhof
andrew at beekhof.net
Thu May 19 07:05:13 UTC 2011
On Tue, May 17, 2011 at 12:26 PM, Dejan Muhamedagic <dejanmm at fastmail.fm> wrote:
> 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).
I did. I thought you were asking how my schema worked.
>
>> 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)?
Yes. Your schema allows a b [c d] e f [g h] i j, which frankly sucks
to parse and read and I don't think it adds value to support it.
> 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.
>From where? It is presumably using the bad ordering semantics we're
trying to remove and should be read in reverse.
>
>> > <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.
Its a lot of extra work to reduce a minimal amount of XML scaffolding
that the vast majority of people will never see (since they use the
shell) and introduces unnecessary confusion as to which syntax is
"correct".
>
>> >> 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.
I added the internal- prefix to fix it in people's minds that it
applied to the members of the set and not between the sets themselves.
>
> And how about "collocation" instead of "colocation"? At least my
> dictionaries prefer the former spelling.
Apparently either form is correct:
http://en.wikipedia.org/wiki/Colocation
So I guess we should use colocation to be consistent with the constraint name.
>
> 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
>
> _______________________________________________
> 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