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" <y...@suse.com>
To: The Pacemaker cluster resource manager
<pacemaker@oss.clusterlabs.org>
Subject: Re: [Pacemaker] symmetrical ordering flaw for multi-state
resources
Message-ID: <5425524b.9010...@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@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 <y...@suse.com>
Senior Software Engineer
SUSE LINUX Products GmbH
------------------------------
Message: 4
Date: Fri, 26 Sep 2014 14:07:56 +0200
From: Felix Zachlod <fz.li...@sis-gmbh.info>
To: pacemaker@oss.clusterlabs.org
Subject: Re: [Pacemaker] Force Pacemaker to not monitor resources on a
node
Message-ID: <5425571c.9010...@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 <arn...@arnoldarts.de>
To: pacemaker@oss.clusterlabs.org
Subject: Re: [Pacemaker] Force Pacemaker to not monitor resources on a
node
Message-ID: <20140926214000.69f84...@xingu.arnoldarts.de>
Content-Type: text/plain; charset="us-ascii"
Hi,
On Fri, 26 Sep 2014 12:46:30 +0200 Felix Zachlod
<fz.li...@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@oss.clusterlabs.org
http://oss.clusterlabs.org/mailman/listinfo/pacemaker
End of Pacemaker Digest, Vol 82, Issue 43
*****************************************
_______________________________________________
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
