Here's an example of the before and after. Thoughts?
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
>>>
>>
>
_______________________________________________
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
