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 1474905 - stonith: dynamic enabling/disabling of stonith resources by rule-constraints
Summary: stonith: dynamic enabling/disabling of stonith resources by rule-constraints
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise Linux 8
Classification: Red Hat
Component: pacemaker
Version: 8.0
Hardware: All
OS: Linux
medium
medium
Target Milestone: pre-dev-freeze
: ---
Assignee: Klaus Wenninger
QA Contact: cluster-qe@redhat.com
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-07-25 15:28 UTC by John Ruemker
Modified: 2023-09-14 04:01 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Enhancement
Doc Text:
Clone Of:
Environment:
Last Closed: 2020-12-01 07:29:19 UTC
Type: Bug
Target Upstream Version:
Embargoed:
pm-rhel: mirror+

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Bugzilla 1470262 0 urgent CLOSED disabling a fencing-device that has queued actions leads to stonithd receiving SIGABRT 2021-02-22 00:41:40 UTC
Red Hat Bugzilla 1474463 0 urgent CLOSED fencing-device not properly registered after disable/enable cycle 2021-02-22 00:41:40 UTC

Internal Links: 1470262 1474463

Description John Ruemker 2017-07-25 15:28:59 UTC 
Description of problem: This is spawning from discussions in Bug #1444020 around a specific customer's goals to add more intelligence around fencing decisions.  In those discussions it was agreed that what I'm about to describe might be more generally useful to others.   

This request is to have stonith devices be manageable via rule-based constraints, allowing them to follow node attributes (or anything else rule expressions can do).  The expectation would be for the result to be similar to stonith devices' following of location constraints - in that if you negative-constrain a stonith device against a node, that node should be unable to use that stonith device to fence another.  With a rule-based constraint, you could have decisions to enable or disable a device from a particular node based on node attributes that may be populated by a resource (like ping, for example).

This would be useful for influencing the stonith behavior based on conditions throughout the cluster.  With a ping resource populating heuristics, you could determine the winner of a membership split through activation of the stonith device on a node that has connectivity to clients.  Other decisions could be made through custom agents or through other node attributes.  


Version-Release number of selected component (if applicable): pacemaker in RHEL 7
Comment 1 John Ruemker 2017-07-25 15:36:25 UTC 
Copying relevant part from Klaus of Comment #40 from 1444020 discussing this:

~~~
location-rules for fencing-resources may not contain anything dynamic like attributes as they are just evaluated once upon startup and when they are altered but not if e.g. an attribute changes.

This being unchanged requires location-rules (or pcs stonith enable/disable) to be altered dynamically based on heuristics results by a script.
This could be a resource with location-constraints using the pingd-attribute.
RA would then enable/disable the fencing resource.
This would just work of course with a small totem-timeout as starting/stopping the resource wouldn't be done once the DC-election is over (at least on the side that isn't DC prior to split).
If hacked into /usr/lib/ocf/resource.d/pacemaker/ping (additional attribute giving a fencing-resource to enable/disable based on a threshold of the node-attribute otherwise updated) the high totem-timeout shouldn't be that crucial as the monitor should be driven autonomously by lrmd.

Of course a cleaner alternative that doesn't require an additional script/resource would be to somehow enable dynamic location-constraints for fencing-resources.
This could either be full support for rules as with other resources than fencing. (Quite complex either pulling pengine into stonithd or having additional syncing between stonithd & pengine - with all drawbacks of lags, non-local communication, ...)
Or some light-weight implementation of a subset like e.g. the possibility to list a node-attribute in the in the fencing-resource-config stonithd will then monitor. Don't know which implications this finally has implementation-wise but at least no communication between nodes is needed and no additional pengine-runs inside stonithd.
~~~
Comment 3 Ken Gaillot 2017-08-01 16:33:24 UTC 
Due to capacity constraints, this is unlikely to be addressed in the 7.5 timeframe. The approach in Bug 1476401 is more likely
Comment 8 RHEL Program Management 2020-12-01 07:29:19 UTC 
After evaluating this issue, there are no plans to address it further or fix it in an upcoming release.  Therefore, it is being closed.  If plans change such that this issue will be fixed in an upcoming release, then the bug can be reopened.
Comment 9 Red Hat Bugzilla 2023-09-14 04:01:36 UTC 
The needinfo request[s] on this closed bug have been removed as they have been unresolved for 1000 days
Note You need to log in before you can comment on or make changes to this bug.