[Pacemaker] [Question] About replacing in resource_set of the order limitation.

[Andrew Beekhof]

On 17 Feb 2014, at 12:47 pm, renayama19661014 at ybb.ne.jp wrote:

> Hi Andrew,
> 
> Thank you for comments.
> 
>> Is this related to your email about symmetrical not being defaulted consistently between colocate_rsc_sets() and unpack_colocation_set()?
> 
> Yes.
> I think that a default is not handled well.
> I will not have any problem when "sequential" attribute is set in cib by all means.
> 
> I think that I should revise processing when "sequential" attribute is not set.

agreed. I've changed some occurrences locally but there may be more.

> 
> Best Regards,
> Hideo Yamauchi.
> 
>> 
>> On 22 Jan 2014, at 3:05 pm, renayama19661014 at ybb.ne.jp wrote:
>> 
>>> Hi All,
>>> 
>>> My test seemed to include a mistake.
>>> It seems to be replaced by two limitation.
>>> 
>>>> However, I think that symmetircal="false" is applied to all order limitation in this.
>>>> (snip)
>>>>        <rsc_order id="rsc_order-clnPing-grpPg1" score="0" symmetrical="false">
>>>>          <resource_set id="rsc_order-clnPing-grpPg1-0">
>>>>            <resource_ref id="clnPing"/>
>>>>          </resource_set>
>>>>          <resource_set id="rsc_order-clnPing-grpPg1-1".....>
>>>>            <resource_ref id="A"/>
>>>>            .......
>>>>            <resource_ref id="F"/>
>>>>          </resource_set>
>>>>        </rsc_order>
>>>> (snip)
>>> 
>>> 
>>>       <rsc_order id="rsc_order-clnPing-grpPg1" score="0" first="clnPing" then="prmEx" symmetrical="false">
>>>       </rsc_order>
>>>       <rsc_order id="rsc_order-clnPing-grpPg2" score="0" symmetrical="true">
>>>         <resource_set id="rsc_order-clnPing-grpPg2-0" require-all="false">
>>>           <resource_ref id="prmEx"/>
>>>           <resource_ref id="prmFs1"/>
>>>           <resource_ref id="prmFs2"/>
>>>           <resource_ref id="prmFs3"/>
>>>           <resource_ref id="prmIp"/>
>>>           <resource_ref id="prmPg"/>
>>>         </resource_set>
>>>       </rsc_order>
>>> 
>>> If my understanding includes a mistake, please point it out.
>>> 
>>> Best Reagards,
>>> Hideo Yamauchi.
>>> 
>>> --- On Fri, 2014/1/17, renayama19661014 at ybb.ne.jp <renayama19661014 at ybb.ne.jp> wrote:
>>> 
>>>> Hi All,
>>>> 
>>>> We confirm a function of resource_set.
>>>> 
>>>> There were the resource of the group and the resource of the clone.
>>>> 
>>>> (snip)
>>>> Stack: corosync
>>>> Current DC: srv01 (3232238180) - partition WITHOUT quorum
>>>> Version: 1.1.10-f2d0cbc
>>>> 1 Nodes configured
>>>> 7 Resources configured
>>>> 
>>>> 
>>>> Online: [ srv01 ]
>>>> 
>>>> Resource Group: grpPg
>>>>       A      (ocf::heartbeat:Dummy): Started srv01 
>>>>       B      (ocf::heartbeat:Dummy): Started srv01 
>>>>       C      (ocf::heartbeat:Dummy): Started srv01 
>>>>       D      (ocf::heartbeat:Dummy): Started srv01 
>>>>       E      (ocf::heartbeat:Dummy): Started srv01 
>>>>       F      (ocf::heartbeat:Dummy): Started srv01 
>>>> Clone Set: clnPing [prmPing]
>>>>       Started: [ srv01 ]
>>>> 
>>>> Node Attributes:
>>>> * Node srv01:
>>>>      + default_ping_set                  : 100       
>>>> 
>>>> Migration summary:
>>>> * Node srv01: 
>>>> 
>>>> (snip)
>>>> 
>>>> These have limitation showing next.
>>>> 
>>>> (snip)
>>>>        <rsc_colocation id="rsc_colocation-grpPg-clnPing" score="INFINITY" rsc="grpPg" with-rsc="clnPing">
>>>>        </rsc_colocation>
>>>>        <rsc_order id="rsc_order-clnPing-grpPg" score="0" first="clnPing" then="grpPg" symmetrical="false">
>>>>        </rsc_order>
>>>> (snip)
>>>> 
>>>> 
>>>> We tried that we rearranged a group in resource_set.
>>>> I think that I can rearrange the limitation of "colocation" as follows.
>>>> 
>>>> (snip)
>>>>        <rsc_colocation id="rsc_colocation-grpPg-clnPing" score="INFINITY">
>>>>          <resource_set id="rsc_colocation-grpPg-clnPing-0">
>>>>            <resource_ref id="clnPing"/>
>>>>            <resource_ref id="A"/>
>>>>            .......
>>>>            <resource_ref id="F"/>
>>>>          </resource_set>
>>>>        </rsc_colocation>
>>>> (snip)
>>>> 
>>>> How should I rearrange the limitation of "order" in resource_set?
>>>> 
>>>> I thought that it was necessary to list two of the next, but a method to express well was not found.
>>>> 
>>>> * "symmetirical=true" is necessary between the resources that were a group(A to F).
>>>> * "symmetirical=false" is necessary between the resource that was a group(A to F) and the clone resources.
>>>> 
>>>> I wrote it as follows.
>>>> However, I think that symmetircal="false" is applied to all order limitation in this.
>>>> (snip)
>>>>        <rsc_order id="rsc_order-clnPing-grpPg1" score="0" symmetrical="false">
>>>>          <resource_set id="rsc_order-clnPing-grpPg1-0">
>>>>            <resource_ref id="clnPing"/>
>>>>          </resource_set>
>>>>          <resource_set id="rsc_order-clnPing-grpPg1-1".....>
>>>>            <resource_ref id="A"/>
>>>>            .......
>>>>            <resource_ref id="F"/>
>>>>          </resource_set>
>>>>        </rsc_order>
>>>> (snip)
>>>> 
>>>> Best Reards,
>>>> Hideo Yamauchi.
>>>> 
>>>> 
>>>> 
>>>> _______________________________________________
>>>> 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://bugs.clusterlabs.org
>>>> 
>>> 
>>> _______________________________________________
>>> 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://bugs.clusterlabs.org
>> 
>> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 841 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <https://lists.clusterlabs.org/pipermail/pacemaker/attachments/20140217/7db183b8/attachment-0003.sig>