Bug 1448773 - PE Restarts resources on remote nodes when the connection is recovered
Summary: PE Restarts resources on remote nodes when the connection is recovered
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: pacemaker
Version: 7.3
Hardware: Unspecified
OS: Unspecified
urgent
urgent
Target Milestone: rc
: 7.4
Assignee: Andrew Beekhof
QA Contact: Udi Shkalim
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-05-08 03:59 UTC by Andrew Beekhof
Modified: 2017-08-01 17:57 UTC (History)
6 users (show)

Fixed In Version: pacemaker-1.1.16-12.el7
Doc Type: Bug Fix
Doc Text:
Cause: Consequence: Pacemaker could unnecessarily restart resources running on a Pacemaker Remote node when the node's connection needed to be recovered. Fix: Result: Pacemaker now does not restart resources on a Pacemaker Remote node whose connection is being recovered, unless necessary.
Clone Of:
Environment:
Last Closed: 2017-08-01 17:57:08 UTC


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Red Hat Product Errata RHEA-2017:1862 normal SHIPPED_LIVE pacemaker bug fix and enhancement update 2017-08-01 18:04:15 UTC

Description Andrew Beekhof 2017-05-08 03:59:35 UTC
Description of problem:

PE Restarts resources on remote nodes when the connection is recovered

Version-Release number of selected component (if applicable):

<= 7.4

How reproducible:

100%

Steps to Reproduce:
1. Grab 1st attachment from bug #1448772
2. crm_simulate -Sx {attachment}
3.

Actual results:

 * Resource action: galera          demote on galera-0
...
 * Resource action: galera          demote on galera-2
...
 * Resource action: galera          stop on galera-0
...
 * Resource action: galera          stop on galera-2
...
 * Resource action: galera          start on galera-2
 * Resource action: galera          start on galera-0


Expected results:

The galera resource (as opposed to the galera-N nodes) are left alone

Additional info:

Comment 2 Andrew Beekhof 2017-05-09 02:36:49 UTC
Just confirmed this was also the behaviour in 1.1.16

Comment 3 Ken Gaillot 2017-05-09 19:53:08 UTC
Confirmed that this behavior also occurs in both RHEL 7.3's 1.1.15-11.el7_3.4 and RHEL 6.8's 1.1.14-8.el6

Comment 4 Ken Gaillot 2017-05-26 23:33:06 UTC
Fixed by upstream commits bc9ba911 through 1d735f0

Comment 5 Andrew Beekhof 2017-06-08 23:26:41 UTC
This bug is critical for OSP 12 which heavily features remote nodes due to the containerization effort.  Therefore it seems appropriate that OSP QE take this on.

Re-requesting 'exception?'

Comment 8 Marian Krcmarik 2017-06-26 13:49:06 UTC
Output from provided reproducer:
 * Pseudo action:   messaging-1_stop_0
 * Pseudo action:   galera-0_stop_0
 * Pseudo action:   galera-2_stop_0
 * Resource action: messaging-1     start on controller-2
 * Resource action: galera-0        start on controller-2
 * Resource action: galera-2        start on controller-2
 * Resource action: rabbitmq        monitor=10000 on messaging-1
 * Resource action: galera          monitor=10000 on galera-2
 * Resource action: galera          monitor=10000 on galera-0
 * Resource action: messaging-1     monitor=20000 on controller-2
 * Resource action: galera-0        monitor=20000 on controller-2
 * Resource action: galera-2        monitor=20000 on controller-2

No demote action is being triggered - verified.

Comment 9 errata-xmlrpc 2017-08-01 17:57:08 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHEA-2017:1862


Note You need to log in before you can comment on or make changes to this bug.