[Pacemaker] Order Constraint for: stop rscA only when rscB is running ?

[Andrew Beekhof]

On Oct 9, 2008, at 3:55 PM, Andreas Kurz wrote:

> On Thursday 09 October 2008 13:58:26 Andrew Beekhof wrote:
>> On Oct 9, 2008, at 12:40 PM, Andreas Kurz wrote:
>>> On Monday 06 October 2008 15:36:31 Andrew Beekhof wrote:
>>>> On Thu, Oct 2, 2008 at 10:23, Andreas Kurz
>>>>
>>>> <andreas.kurz at linbit.com> wrote:
>>>>> Hi,
>>>>>
>>>>> I have a Heartbeat 2.1.3 two-node cluster and I wonder if there is
>>>>> a way
>>>>> to create constraints that work like that:
>>>>>
>>>>> * Two resources (rscA and rscB) of class "heartbeat" that should  
>>>>> run
>>>>> together on one node .... simple advisory colocation constraint
>>>>>
>>>>> <rsc_colocation id="rscA-colocated-with-rscB"
>>>>>      from="rscA" to="rscB"
>>>>>      score="1" symmetrical="true"/>
>>>>>
>>>>> * When doing maintenance on one node I put the node into standby
>>>>> mode and
>>>>> want rscA only stop and migrate away if rscB is already up and
>>>>> running on
>>>>> the other node and vice versa because  there must always run at
>>>>> least one
>>>>> of these resources in the cluster.
>>>>>
>>>>> I added two order_constraints and tested it with ptest on an
>>>>> adapted live
>>>>> cib but they seem to produce a loop:
>>>>
>>>> This is logical if you draw it out (and remember that Stop X always
>>>> precedes Start X)
>>>
>>> Yes, I expected a loop and I had a slide hope there is some
>>> cool "prevent-loops" logic available ;-)
>>
>> Possible in theory - but there is no way to know where the "right"
>> place to break the chain is.
>
> Maybe using the priority of the resources to break the chain?

Still wont help you, since every link in the chain is "required".

>>>> Any reason not to just use the following?
>>>>
>>>> <rsc_order id="always-start-A-after-B"
>>>>      from="service_rscB" action="start"
>>>>      type="before"
>>>>      to="service_rscA" to_action="start"
>>>>      symmetrical="true" score="0"/>
>>>
>>> The reason is that first rscA then rscB ist stopped ... so they are
>>> both down
>>> before they are restarted in this order on the other node.
>>>
>>> The idea is ... in case of a manual switchover of all services from
>>> nodeA to
>>> nodeB during regular failover tests, rscA should be stopped on nodeA
>>> _after_
>>> rscB is already _started_ on nodeB.
>>
>> But in normal operation rscB should start after rscA?
>
> This is not necessary, the should run together on one node in normal
> operation, for a short period of time they can run on different  
> nodes ... the
> only realy demand is: keep at least one of these resources running

>>>>> <rsc_order id="stop-rscA-only-after-rscB-start"
>>>>>      from="service_rscA" action="stop"
>>>>>      type="after"
>>>>>      to="service_rscB" to_action="start"
>>>>>      symmetrical="false" score="0"/>

Then just this constraint should work should it not?

If A and B are both restarting, then A will always wait for B to be  
active.
If only A is restarting, then B will still be active.
If only B is restarting, then A will still be active.

If A and B are stopping, the constraint is ignored.
If A is stopping, and B remains (in)active, the constraint is ignored.
If B is stopping, and A remains (in)active, the constraint is ignored.

Did I miss something?


>>>>>
>>>>>
>>>>> <rsc_order id="stop-rscB-only-after-rscA-start"
>>>>>      from="service_rscB" action="stop"
>>>>>      type="after"
>>>>>      to="service_rscA" to_action="start"
>>>>>      symmetrical="false" score="0"/>
>>>>>
>>>>> Is there a way to get the requested behavior or is a manual  
>>>>> resource
>>>>> after resource migration the only way to achieve this?
> ...
>
> -- 
> : Andreas Kurz					
> : LINBIT | Your Way to High Availability
> : Tel +43-1-8178292-64, Fax +43-1-8178292-82
> :
> : http://www.linbit.com
>
> DRBD® and LINBIT® are registered trademarks of LINBIT, Austria.
>
> This e-mail is solely for use by the intended recipient(s).  
> Information
> contained in this e-mail and its attachments may be confidential,
> privileged or copyrighted. If you are not the intended recipient you  
> are
> hereby formally notified that any use, copying, disclosure or
> distribution of the contents of this e-mail, in whole or in part, is
> prohibited. Also please notify immediately the sender by return e-mail
> and delete this e-mail from your system. Thank you for your co- 
> operation.
> _______________________________________________
> Pacemaker mailing list
> Pacemaker at clusterlabs.org
> http://list.clusterlabs.org/mailman/listinfo/pacemaker