[Pacemaker] symmetrical ordering flaw for multi-state resources

Tue Sep 30 11:50:02 EDT 2014

Thank Yan for the answer.

I think I found the issue. If you change the first action from "start" to "promote" than the issue happens (which was what I was using):

    order order-msA-msB Mandatory: msA:promote msB:start symmetrical=false

with meta attribute interleave=true.

Why is there a difference here between the two actions? In other words, why does it work when we use:
    order order-msA-msB Mandatory: msA:start msB:start symmetrical=false

and not when we use:
    order order-msA-msB Mandatory: msA:promote msB:start symmetrical=false

Thanks,

Youssef

-----Original Message-----
Date: Fri, 26 Sep 2014 13:47:23 +0200
From: "Gao,Yan" <ygao at suse.com>
To: The Pacemaker cluster resource manager
	<pacemaker at oss.clusterlabs.org>
Subject: Re: [Pacemaker] symmetrical ordering flaw for multi-state
	resources
Message-ID: <5425524B.9010600 at suse.com>
Content-Type: text/plain; charset=windows-1252

Hi Youssef,

Is the order like:

order order-msA-msB Mandatory: msA:start msB:start symmetrical=false

? and msA and msB have the meta attribute interleave=true? If so and it doesn't work, please collect a hb_report/crm_report covering the issue.

Regards,
  Yan

On 09/25/2014 08:13 PM, Latrous, Youssef wrote:
> Reposting from few weeks ago as I didn't get any answer yet :-(
> 
> I included below the original post and tried to rephrase it in this second one, hoping my concern will be understood.
> 
> I tried to use a dummy multi-state RA and have an asymmetrical ordering dependency to another resource (B). While an equivalent ordering to the same resource, but from a regular resource, works just fine, it did not work for the multi-state RA. What I mean by it didn't work is that it stopped the multi-state RA, when the resource (B) was stopped, but the regular resource kept running as expected (and documented in pacemaker)!
> 
> Is this a bug in pacemaker or is it known to not work with multi-state RAs? Other possibility, there a different way of using the "symmetrical" option for multi-state RA ordering?
> 
> Please, help!
> 
> Regards,
> 
> Youssef
> 
> PS. Below is the original post.
> 
> Hi,
> 
> I was trying to express the following:
>    * Configure 3 resources:
>       * A: multi-state resource
>       * B: another multi-state resource
>       * C: regular primitive
>    * On startup sequence, when all resources were previously stopped, ensure the following mandatory ordering:
>       * A starts, then B
>       * A starts, then C
>    * After that, if A fails or restarts, do not impact B and C
> 
> The docs state that setting the "symmetrical" option to "false" (...symmetrical=false) on the corresponding ordering constraints does the trick.
> This works just fine for resource C, but not for resource B.
> 
> Is there a restriction I'm not aware of for the multi-state resources with regard to this option? That is the option "symmetrical" doesn't take effect on multi-state resources. Is there something extra that needs to be done/specified for the multi-state resources?
> 
> Regards,
> 
> Youssef L.
> 
> 
> _______________________________________________
> 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
> 
> 

--
Gao,Yan <ygao at suse.com>
Senior Software Engineer
SUSE LINUX Products GmbH

------------------------------

Message: 4
Date: Fri, 26 Sep 2014 14:07:56 +0200
From: Felix Zachlod <fz.lists at sis-gmbh.info>
To: pacemaker at oss.clusterlabs.org
Subject: Re: [Pacemaker] Force Pacemaker to not monitor resources on a
	node
Message-ID: <5425571C.9010704 at sis-gmbh.info>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

Am 26.09.2014 12:46, schrieb Felix Zachlod:
> Hello List,
>
> I am currently trying to add a third node only for giving a quorum a to
> the cluster in case a servicing node fails. But oviously I can't get it
> right.

Ok just to answer myself quickly. I found out that symetric-cluster="false"

and specifying explicit location constraints for every allowed 
resource-node colocation does the trick.

So no answer needed anymore,

thanks, Felix

------------------------------

Message: 5
Date: Fri, 26 Sep 2014 21:40:00 +0200
From: Arnold Krille <arnold at arnoldarts.de>
To: pacemaker at oss.clusterlabs.org
Subject: Re: [Pacemaker] Force Pacemaker to not monitor resources on a
	node
Message-ID: <20140926214000.69f84b6a at xingu.arnoldarts.de>
Content-Type: text/plain; charset="us-ascii"

Hi,

On Fri, 26 Sep 2014 12:46:30 +0200 Felix Zachlod
<fz.lists at sis-gmbh.info> wrote:
> I am currently trying to add a third node only for giving a quorum a
> to the cluster in case a servicing node fails. But oviously I can't
> get it right.
<snip>
> This is the message from crm status:
> 
> Failed actions:
>      drbd_testdata1:0_monitor_0 (node=storage-voter, call=9, rc=5, 
> status=complete): not installed
> 
> Can anyone give me a hint how to solve this? As said storage-voter
> will never run any resource although it would be nive if it could
> trigger stonith actions anyway.

Additional to your own findings:

When the cluster is symmetric, the monitor action _will_ be called on
all nodes. The reason is that you told to cluster to be responsible to
run your resource. And also to be responsible that the resource isn't
running where it shouldn't. So it runs the monitor action at least once
on every node to make sure the resource isn't somewhere where it
doesn't belong.

The failure of "not installed" is then exactly what you want to have
there. And its far less critical to get a failed monitor action on the
node where it shouldn't run then when a resource is actually running on
a node where cluster is expecting it and subsequently a start-action
failing on another node.

Have a nice weekend,

Arnold
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 230 bytes
Desc: not available
URL: <http://oss.clusterlabs.org/pipermail/pacemaker/attachments/20140926/33dab7e7/attachment-0001.sig>

------------------------------

_______________________________________________
Pacemaker mailing list
Pacemaker at oss.clusterlabs.org
http://oss.clusterlabs.org/mailman/listinfo/pacemaker

End of Pacemaker Digest, Vol 82, Issue 43
*****************************************