[Pacemaker] Pacemaker unnecessarily (?) restarts a vm on active node when other node brought out of standby - possible solution?

[Andrew Beekhof]

On 19 May 2014, at 4:17 pm, Andrew Beekhof <andrew at beekhof.net> wrote:

> 
> On 16 May 2014, at 3:41 am, Ian <cl-3627 at jusme.com> wrote:
> 
>> Doing some experiments and Reading TFM, I found this:
>> 
>> 5.2.2. Advisory Ordering
>> When the kind=Optional option is specified for an order constraint, the constraint is considered optional and only has an effect when both resources are stopping and/or starting. Any change in state of the first resource you specified has no effect on the second resource you specified.
>> 
>> (From https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Configuring_the_Red_Hat_High_Availability_Add-On_with_Pacemaker/index.html)
>> 
>> This seems to tickle the right area. Adding "kind=Optional" to the gfs2 -> drbd order constraint makes it all work as desired (start-up and shut-down is correctly ordered,
> 
> Not really, it allows gfs2 to start even if drbd can't run anywhere.
> 
>> and bringing the other node out of standby doesn't force a gratuitous restart of the gfs2 filesystem and the vms that rely on it on the already active node).
>> 
>> Is that the correct solution I wonder?
> 
> Unlikely

I've filed a bug for this so it doesn't get lost:

   http://bugs.clusterlabs.org/show_bug.cgi?id=5214

It may not make the cut for 1.1.12 though since dual masters isn't a common use case.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 841 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <https://lists.clusterlabs.org/pipermail/pacemaker/attachments/20140520/dea7b0c3/attachment-0003.sig>