On 17 Feb 2014, at 12:47 pm, renayama19661...@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, renayama19661...@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, renayama19661...@ybb.ne.jp >>> <renayama19661...@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@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@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 >> >>
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ 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://bugs.clusterlabs.org