[Pacemaker] crm shell and collocating sets

[Andrew Beekhof]

On Mon, Jan 24, 2011 at 4:56 PM, Vadym Chepkov <vchepkov at gmail.com> wrote:
> On Mon, Jan 24, 2011 at 10:41 AM, Dejan Muhamedagic <dejanmm at fastmail.fm> wrote:
>> Hi,
>>
>> On Sat, Jan 22, 2011 at 01:38:12PM -0500, Vadym Chepkov wrote:
>>> Hi,
>>>
>>> It seems crm shell can't express sequential="true" in  collocating sets, which is strange, since, I assume, it's a default.
>>>
>>> If you load an example using cibadmin from "Configuration explained"
>>>
>>> Example 6.16. Using colocation sets to specify a common peer.
>>>   <constraints>
>>>     <rsc_colocation id="coloc-1" score="INFINITY" >
>>>       <resource_set id="collocated-set-1" sequential="false">
>>>         <resource_ref id="A"/>
>>>         <resource_ref id="B"/>
>>>         <resource_ref id="C"/>
>>>       </resource_set>
>>>       <resource_set id="collocated-set-2" sequential="true">
>>>         <resource_ref id="D"/>
>>>       </resource_set>
>>>     </rsc_colocation>
>>>   </constraints>
>>>
>>>
>>> It will look like this in crm configure show output:
>>>
>>> xml <rsc_colocation id="coloc-1" score="INFINITY"> \
>>>       <resource_set id="collocated-set-1" sequential="false"> \
>>>               <resource_ref id="A"/> \
>>>               <resource_ref id="B"/> \
>>>               <resource_ref id="C"/> \
>>>       </resource_set> \
>>>       <resource_set id="collocated-set-2" sequential="true"> \
>>>               <resource_ref id="D"/> \
>>>       </resource_set> \
>>> </rsc_colocation>
>>>
>>> Not exactly a "simplification"
>>>
>>> Am I missing something? How one would express the same constraint using shell?
>>
>> By omitting sequential="true". The problem is that two XML
>> representation have the same meaning, but look slightly
>> different, which again makes shell think that it could've done
>> something wrong while rendering XML from the CLI presentation.
>>
>> Anyway, that should be fixed somehow.
>>
>> Thanks,
>>
>> Dejan
>
> If you ever consider do something about it, here is another thing that
> can be lived with, but is non-intuitive.
>
> 1) colocation c1 inf: A B
>
> the most significant is B (if B is stopped nothing else will be running)
>
> 2) colocation c2 inf: A B C
>
> most significant - A
>
> 3) colocation c3 inf: ( A B ) C
>
> most significant - C
>
> 4) colocation c4 inf: ( A B ) C D
>
> most significant - C again
>
> I am trying to find a logic to remember this, but fails so far :)

No wonder, it was not at all what I intended to write, nor what I
documented for the xml.

As we've been discussing elsewhere recently, 1 and 2 make sense - its
the same implicit ordering as groups.
The breakdown is 3 and 4 which have the opposite ordering to 1 and 2.

So after all my moaning about the shell, it looks like I owe Dejan a
large apology - the problem was in the xml all along.

The good news is that we can use the opportunity to fix the other
annoying things about the sets syntax - we just need to figure out the
details of the upgrade process.