On 08/04/2013, at 4:11 PM, renayama19661...@ybb.ne.jp wrote: > Hi Andrew, > > Thank you for comments. > >>>>> Using ordering_set and colocation_set, is it impossible to perform >>>>> movement same as "ordered=false" of the group resource? >>>> >>>> Yes, because they're not the same thing. >>>> >>>> Setting "sequential=false" is not at all like setting "ordered=false". >>>> Setting "ordered=false" is the equivalent of _removing_ <rsc_order >>>> id="test-order"> completely. >>> >>> Which next case does your answer correspond to? >> >> I was answering Case 4 as thats where I saw the '?'. >> However it equally applies to all cases. >> >> If you do not want ordering, do not define an ordering constraint. >> > > Okay! > > I changed case 4 and carried it out.(remove <rsc_order id="test-order">.) > > (snip) > <group id="testGroup01"> > <primitive class="ocf" type="Dummy" provider="heartbeat" > id="vip-master"> > (snip) > <primitive class="ocf" type="Dummy" provider="heartbeat" id="vip-rep"> > </group> > (snip) > <constraints> > <rsc_colocation id="test-colocation"> > <resource_set sequential="false" > id="test-colocation-resource_set"> > <resource_ref id="vip-master"/> > <resource_ref id="vip-rep"/> > </resource_set> > </rsc_colocation> > </constraints> > > (snip) > [root@rh64-heartbeat1 ~]# grep "Initiating action" /var/log/ha-log > Apr 8 23:46:32 rh64-heartbeat1 crmd: [3171]: info: te_rsc_command: > Initiating action 2: probe_complete probe_complete on rh64-heartbeat1 (local) > - no waiting > Apr 8 23:47:59 rh64-heartbeat1 crmd: [3171]: info: te_rsc_command: > Initiating action 4: monitor vip-master_monitor_0 on rh64-heartbeat1 (local) > Apr 8 23:47:59 rh64-heartbeat1 crmd: [3171]: info: te_rsc_command: > Initiating action 5: monitor vip-rep_monitor_0 on rh64-heartbeat1 (local) > Apr 8 23:47:59 rh64-heartbeat1 crmd: [3171]: info: te_rsc_command: > Initiating action 3: probe_complete probe_complete on rh64-heartbeat1 (local) > - no waiting > Apr 8 23:47:59 rh64-heartbeat1 crmd: [3171]: info: te_rsc_command: > Initiating action 6: start vip-master_start_0 on rh64-heartbeat1 (local) > Apr 8 23:47:59 rh64-heartbeat1 crmd: [3171]: info: te_rsc_command: > Initiating action 1: stop vip-master_stop_0 on rh64-heartbeat1 (local) > > (snip) > ============ > Last updated: Mon Apr 8 23:48:04 2013 > Stack: Heartbeat > Current DC: rh64-heartbeat1 (d2016b22-145f-4e6a-87a4-a05f7c5a9c29) - > partition with quorum > Version: 1.0.13-30bb726 > 1 Nodes configured, unknown expected votes > 1 Resources configured. > ============ > > Online: [ rh64-heartbeat1 ] > > > Node Attributes: > * Node rh64-heartbeat1: > > Migration summary: > * Node rh64-heartbeat1: > vip-master: migration-threshold=1 fail-count=1000000 > > Failed actions: > vip-master_start_0 (node=rh64-heartbeat1, call=4, rc=1, status=complete): > unknown error > > However, the result was the same. > > When start trouble of vip-master happens, vip-rep does not do start. > The order of start of the resource seems to be controlled. > > Possibly is it a problem of Pacemaker1.0? > Do you move well in Pacemaker1.1?
Oh! I somehow failed to recognise that you were using 1.0 There is a reasonable chance that 1.1 behaves better in this regard. I also notice, now, that the resources are still in a group - deleting the ordering constraint achieves nothing if the resources are still in a group. Just define the resources and the colocation set, no group. > > Best Regards, > 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