[Pacemaker] [Problem] Order is ignored, and promote is carried out.

[renayama19661014 at ybb.ne.jp]

Hi Phillip,

Thank you for comment.
However, the result was the same even if I used the Group resource.

(snip)
      <group id="GrpvipCheck">      <primitive class="ocf" id="vipCheck" provider="pacemaker" type="Dummy">        <instance_attributes id="vipCheck-instance_attributes">        </instance_attributes>        <operations>          <op id="vipCheck-start-0s" interval="0s" name="start" on-fail="restart" start-delay="4s" timeout="90s"/>        </operations>      </primitive>
      </group>
(snip)
      <rsc_order first="GrpvipCheck" first-action="start" id="rsc_order-7" score="INFINITY" then="msPostgresql" then-action="promote"/>
(snip)

============
Last updated: Mon Jul  2 17:56:27 2012
Stack: Heartbeat
Current DC: rh62-test1 (6d534d4e-a3a1-4a92-86c7-eadf6c2f7570) - partition with quorum
Version: 1.0.12-unknown
1 Nodes configured, unknown expected votes
2 Resources configured.
============

Online: [ rh62-test1 ]

 Master/Slave Set: msPostgresql
     Masters: [ rh62-test1 ]
     Stopped: [ postgresql:1 ]

Migration summary:
* Node rh62-test1: 
   vipCheck: migration-threshold=1 fail-count=1000000

Failed actions:
    vipCheck_start_0 (node=rh62-test1, call=4, rc=1, status=complete): unknown error

Best Regards,
Hideo Yamauchi.

--- On Fri, 2012/6/29, Phillip Frost <phil at macprofessionals.com> wrote:

> 
> On Jun 28, 2012, at 10:26 PM, renayama19661014 at ybb.ne.jp wrote:
> 
> >> We set order limitation as follows.
> > 
> >      <rsc_colocation id="rsc_colocation-7" rsc="vipCheck" score="INFINITY" with-rsc="msPostgresql" with-rsc-role="Master"/>
> >      <rsc_order first="vipCheck" first-action="start" id="rsc_order-7" score="INFINITY" then="msPostgresql" then-action="promote"/>
> > 
> >> However, promote was carried out even if primitvei resource caused start trouble.
> >> 
> >> Online: [ rh62-test1 ]
> >> 
> >> Master/Slave Set: msPostgresql
> >>      Masters: [ rh62-test1 ]
> >>      Stopped: [ postgresql:1 ]
> >> 
> >> Migration summary:
> >> * Node rh62-test1: 
> >>    vipCheck: migration-threshold=1 fail-count=1000000
> >> 
> >> Failed actions:
> >>     vipCheck_start_0 (node=rh62-test1, call=4, rc=1, status=complete): unknown error
> 
> What happens if you reverse the order of the of the colocation constraint? You've told pacemaker to decide where to put msPostgresql:Master first, and if it can't run that, then don't run vipCheck, but to start them in the opposite order. I'm not sure an order constraint will prevent one resource from running if another fails to start, but a colocation constraint will, if you get it in the right order.
> 
> You could also use a resource group, which combines colocation and order constraints in the order you'd expect.
>