RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1474463 - fencing-device not properly registered after disable/enable cycle
Summary: fencing-device not properly registered after disable/enable cycle
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: pacemaker
Version: 7.4
Hardware: Unspecified
OS: Unspecified
urgent
urgent
Target Milestone: rc
: 7.5
Assignee: Klaus Wenninger
QA Contact: cluster-qe@redhat.com
URL:
Whiteboard:
Depends On:
Blocks: 1481142
TreeView+ depends on / blocked
 
Reported: 2017-07-24 16:57 UTC by Klaus Wenninger
Modified: 2018-04-10 15:32 UTC (History)
10 users (show)

Fixed In Version: pacemaker-1.1.18-1.el7
Doc Type: Bug Fix
Doc Text:
Previously, Pacemaker's stonithd service used an incorrect search pattern when checking the configuration for re-enabled fence devices. Consequently, re-enabled fence devices were shown to be available only on the node where they had been started. With this update, stonithd now uses the correct search pattern, and the described problem no longer occurs.
Clone Of:
: 1481142 (view as bug list)
Environment:
Last Closed: 2018-04-10 15:30:29 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Bugzilla 1474905 0 medium CLOSED stonith: dynamic enabling/disabling of stonith resources by rule-constraints 2023-09-14 04:01:35 UTC
Red Hat Product Errata RHEA-2018:0860 0 None None None 2018-04-10 15:32:11 UTC

Internal Links: 1474905

Description Klaus Wenninger 2017-07-24 16:57:01 UTC 
Description of problem:

fencing-devices are foreseen to be used even if not shown as started.
It is possible to disable them either via location-rules (no rules that dynamically change their result like score attributes or alike as they are not reevaluated by stonithd) or by explicitely setting the target-role to stopped.
After a diable/enable cycle stonith devices are just used if explicitly started on a node. 


Version-Release number of selected component (if applicable):
1.1.16-12.el7

How reproducible:
100%

Steps to Reproduce:
1. create a fencing-resource-primitive without any rules restricting it to a node
2. restart cluster
3. use crm_mon to assure that fencing-resource accounts as started on one of the cluster nodes
4. use 'stonith_admin -L' to verify that the fencing-resource is available both on the node where it is claimed to be started and on at least one other node
5. issue 'pcs stonith disable {your-fencing-resource}' and 'pcs stonith disable {your-fencing-resource}'

Actual results:
'stonith_admin -L' shows the fencing-resource just on the node where it is claimed to be started

Expected results:
'stonith_admin -L' should show the fencing-resource to be available on all nodes

Additional info:
Comment 2 Klaus Wenninger 2017-07-24 17:01:19 UTC 
cib-diffs are not being checked properly in stonithd to decide if a full parsing should be triggered or not.

https://github.com/ClusterLabs/pacemaker/pull/1314/commits/5e3cd2614e1db60a14d5615c9c175575409b56d6

seems to solve the issue.
Comment 4 michal novacek 2017-08-04 09:56:14 UTC 
qa-ack+: clear reproducer in initial commit
Comment 7 Patrik Hagara 2017-12-05 15:36:42 UTC 
Reproduced as outlined in the first comment:
  * "pcs cluster setup --start --wait ..."
  * "pcs stonith create ..."
  * "pcs cluster stop --all"
  * "pcs cluster start --all --wait"
  * "crm_mon -X"; verify fence resource seen as started on 1 node from all nodes
  * "stonith_admin -L"; verify fence device registered/available on all nodes
  * "pcs stonith disable --wait ..."
  * "pcs stonith enable --wait ..."
  * "crm_mon -X"; verify fence resource seen as started on 1 node from all nodes
  * "stonith_admin -L"; verify fence device still registered/available on all nodes

Before the fix (1.1.16-12.el7) only the node on which the fence resource is in "Started" role sees the corresponding fence device as registered/available, other nodes do not (as reported by "stonith_admin -L"). After the fix (1.1.18-1.el7) all nodes see the fence device as registered/available. Marking verified.
Comment 10 errata-xmlrpc 2018-04-10 15:30:29 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-2018:0860
Note You need to log in before you can comment on or make changes to this bug.