[Pacemaker] [solved] stopping resource stops others in colocation / order sets

[Andreas Kurz]

On 06/15/2012 06:19 PM, Phil Frost wrote:
> On 06/15/2012 11:55 AM, David Vossel wrote:
>>> If resC is stopped
>>>     resource stop resC
>>>
>>> then drbd_nfsexports is demoted, and resB and resC will stop. Why is
>>> that? I'd expect that resC, being listed last in both the colocation
>>> and
>> It is the order constraint.
>>
>> Order constraints are symmetrical. If you say to do these things in
>> this order
>>
>> 1. promote drbd
>> 2. start resB
>> 3. start rscC
>>
>> Then the opposite is also true.  If you want to demote drbd it the
>> following has to happen first.
>>
>> 1. stop rscC
>> 2. stop resB
>> 3. demote drbd
>>
>> You can get around this by using the symmetrical option for your order
>> constraints.
> 
> True, but I wasn't demoting DRBD; I was stopping resource C (mostly to
> see what would happen if for whatever reason, it couldn't run anywhere).
> The order constraint alone doesn't explain the behavior I saw. However,
> I think I've pieced together what was actually happening. This constraint:
> 
> colocation colo inf: drbd_nfsexports_ms:Master resB resC

Yes, unfortunately this is quite confusing in the crm shell syntax.
Because a resource-set can only have one specific role, crm shell
creates in this example two resource-sets. One for the drbd resource and
one for the two simple resources.

So you have two sets. Within the "simple" resource-set resB is more
significant then resC (like in a group).

Between the two resource-sets, drbd depends on the "simple" resource-set
(needs to be Master on the same host) and will be demoted as soon as (at
least) resC is stopped or not runable.

Regards,
Andreas

-- 
Need help with Pacemaker?
http://www.hastexo.com/now

> 
> 
> means, very confusingly, that to be a master, resB and resC must be
> active. Also, for resC to be active, resB must be active. In other words
> (with some transitive reduction applied):
> 
> drbd -> resC -> resB
> 
> It doesn't make any sense, and the documentation is wrong (or at least
> self-conflicting). But that's what it really does mean. What was really
> confusing is that were it not for the :Master modifier, then crm would
> make only one resource set, and it would mean something else. So when I
> was testing with dummy resources, I was only more confused. I made
> another post explaining it more.
> 
> So, DRBD can't be master unless resC and resB are active. And as you
> explained, the order constraint will stop resC and resB if DRBD is
> demoted. Combined, that means either all these things run, or none:
> 
> - resC is stopped, or can't run anywhere
> - (by colocation constraint) DRBD may not be master. Demote it.
> - (by order constraint) stop resC (actually a no-op: it's already stopped)
> - (by order constraint) stop resB
> 
> 
> _______________________________________________
> 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





-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 222 bytes
Desc: OpenPGP digital signature
URL: <https://lists.clusterlabs.org/pipermail/pacemaker/attachments/20120618/b4b08fd9/attachment-0004.sig>