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

[renayama19661014 at ybb.ne.jp]

Hi All,

The constitution of the cluster became right by a redundant resource and addition and a change of the limitation as follows.
However, we do not want to perform the redundant setting.

(snip)
      <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>
      <primitive class="ocf" id="vipCheck2" provider="heartbeat" type="Dummy">
        <instance_attributes id="vipCheck2-instance_attributes">
        </instance_attributes>
        <operations>
          <op id="vipCheck2-start-0s" interval="0s" name="start" on-fail="restart" start-delay="4s" timeout="90s"/>
        </operations>
      </primitive>
(snip)
      <rsc_colocation id="rsc_colocation-7" rsc="vipCheck" score="INFINITY" with-rsc="msPostgresql" with-rsc-role="Master"/>
      <rsc_colocation id="rsc_colocation-8" rsc="vipCheck" score="INFINITY" with-rsc="vipCheck2"/>
      <rsc_order first="vipCheck" first-action="start" id="rsc_order-8" score="INFINITY" then="vipCheck2" then-action="start"/>
      <rsc_order first="vipCheck2" first-action="start" id="rsc_order-7" score="INFINITY" then="msPostgresql" then-action="promote"/>
(snip)
============
Last updated: Mon Jul  2 18:35:19 2012
Stack: Heartbeat
Current DC: rh62-test1 (90e5d5b7-d217-4386-a03d-069111772b54) - partition with quorum
Version: 1.0.12-unknown
1 Nodes configured, unknown expected votes
3 Resources configured.
============

Online: [ rh62-test1 ]

 Master/Slave Set: msPostgresql
     Slaves: [ 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=5, rc=1, status=complete): unknown error


Best Regards,
Hideo Yamauchi.

--- On Mon, 2012/7/2, renayama19661014 at ybb.ne.jp <renayama19661014 at ybb.ne.jp> wrote:

> 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.
> > 
> 
> _______________________________________________
> 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
>