[Pacemaker] [Question]About "sequential" designation of resource_set.

[Andrew Beekhof]

On 08/04/2013, at 4:11 PM, renayama19661014 at 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 at 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 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