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

[Andrew Beekhof]

Is this related to your email about symmetrical not being defaulted consistently between colocate_rsc_sets() and unpack_colocation_set()?

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/f2460065/attachment-0003.sig>