Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.
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 1261116

Summary: Allow targeting by attribute in fencing topology
Product: Red Hat Enterprise Linux 7 Reporter: Ken Gaillot <kgaillot>
Component: pcsAssignee: Tomas Jelinek <tojeline>
Status: CLOSED ERRATA QA Contact: cluster-qe <cluster-qe>
Severity: low Docs Contact: Steven J. Levine <slevine>
Priority: medium    
Version: 7.1CC: cfeist, cluster-maint, idevat, kgaillot, royoung, rsteiger, tojeline
Target Milestone: rcKeywords: FutureFeature
Target Release: ---   
Hardware: All   
OS: All   
Whiteboard:
Fixed In Version: pcs-0.9.156-1.el7 Doc Type: Release Note
Doc Text:
Specifying nodes in fencing topology by a regular expression or a node attribute and its value It is now possible to specify nodes in fencing topology by a regular expression applied on a node name and by a node attribute and its value. For example, the following commands configure nodes `node1`, `node2`, and `node3` to use fence devices `apc1` and `apc2`, and nodes `node4`, `node5`, and `node6` to use fence devices `apc3` and `apc4`. pcs stonith level add 1 "regexp%node[1-3]" apc1,apc2 pcs stonith level add 1 "regexp%node[4-6]" apc3,apc4 The following commands yield the same results by using node attribute matching. pcs node attribute node1 rack=1 pcs node attribute node2 rack=1 pcs node attribute node3 rack=1 pcs node attribute node4 rack=2 pcs node attribute node5 rack=2 pcs node attribute node6 rack=2 pcs stonith level add 1 attrib%rack=1 apc1,apc2 pcs stonith level add 1 attrib%rack=2 apc3,apc4
 Story Points: ---
Clone Of: Environment:
Last Closed: 2017-08-01 18:22:57 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 1403312    
Attachments:
Description Flags
proposed fix none

Description Ken Gaillot 2015-09-08 15:43:12 UTC 
Description of problem: Pacemaker 1.1.14 (specifically upstream master branch as of commit 9d8c075) adds the ability to target fencing topologies by the presence of a node attribute. Current pcs has problems with the new syntax.

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


How reproducible: always


Steps to Reproduce: Try to configure and show fencing topology using new syntax (where target is "NAME=VALUE" or "NAME:VALUE"). Examples:

1. "pcs stonith show" labels all targets with "Node:" but the new syntax is by attribute. Perhaps it could use "Target:" for all, or distinguish "Node:" from "Nodes with attribute/value:".

2. "pcs level add 1 myattr=myvalue device1,device2" returns an error without "--force" because "myattr=myvalue" is not a node, and with "--force" because it tries to use the equals sign in the XML ID, which is invalid. It should check for attribute rather than node presence when an attribute is used, and convert '=' and ':' to something valid in an ID and sufficiently unique.


Actual results: Errors in some operations.


Expected results: Successful operations.


Additional info: See upstream announcement at http://clusterlabs.org/pipermail/developers/2015-September/000072.html
Comment 1 Chris Feist 2015-09-09 21:08:59 UTC 
Just a note the syntax is slightly changing from #1, Ken will update this bug when the new syntax is set in pacemaker.
Comment 2 Ken Gaillot 2015-09-24 19:50:19 UTC 
As of upstream commit 8940fca, he syntax has been updated so as not to use the "target" XML attribute for this purpose, instead adding new "target-attribute" and "target-value" XML attributes. Example:

<fencing-topology>
   <fencing-level id="rack-1-1" index="1"
      target-attribute="rack" target-value="1"
      devices="apc01,apc02" />
</fencing-topology>

A reminder, if using the target-value to generate the id, be aware it can have any characters, while ids are more restrictive. You might want to sanitize the value, hash it, or use an increment instead.

FYI, the existing methods for specifying topology targets are target="NODE_NAME" and target-pattern="NODE_NAME_REGEX". Previously, these were implemented such that someone might have gotten away with using a regex with target instead of target-pattern, but that won't work with the new implementation.
Comment 6 Tomas Jelinek 2016-12-09 15:09:24 UTC 
Created attachment 1230028 [details]
proposed fix

Tests are included in the patch. For command line tests see the pcs/test/test_stonith.py file.
Comment 8 Ivan Devat 2017-02-20 07:44:48 UTC 
After Fix:

[vm-rhel72-1 ~] $ rpm -q pcs
pcs-0.9.156-1.el7.x86_64

[vm-rhel72-1 ~] $ pcs stonith show
 xvm-fencing    (stonith:fence_xvm):    Started vm-rhel72-1
[vm-rhel72-1 ~] $ pcs stonith level add 1 vm-rhel72-2 xvm-fencing
[vm-rhel72-1 ~] $ pcs stonith show
 xvm-fencing    (stonith:fence_xvm):    Started vm-rhel72-1
 Target: vm-rhel72-2
   Level 1 - xvm-fencing

[vm-rhel72-1 ~] $ pcs stonith level add 2 "regexp%vm-rhel72-\d" xvm-fencing
[vm-rhel72-1 ~] $ pcs stonith show
 xvm-fencing    (stonith:fence_xvm):    Started vm-rhel72-1
 Target: vm-rhel72-2
   Level 1 - xvm-fencing
 Target: vm-rhel72-\d
   Level 2 - xvm-fencing

[vm-rhel72-1 ~] $ pcs stonith level add 3 attrib%id=nodes-2 xvm-fencing
CIB has been upgraded to the latest schema version.
[vm-rhel72-1 ~] $ pcs stonith show
 xvm-fencing    (stonith:fence_xvm):    Started vm-rhel72-1
 Target: vm-rhel72-2
   Level 1 - xvm-fencing
 Target: vm-rhel72-\d
   Level 2 - xvm-fencing
 Target: id=nodes-2
   Level 3 - xvm-fencing

[vm-rhel72-1 ~] $ pcs stonith level add 3 attrib%id=nodes-3 xvm-fencing
[vm-rhel72-1 ~] $ pcs stonith show
 xvm-fencing    (stonith:fence_xvm):    Started vm-rhel72-1
 Target: vm-rhel72-2
   Level 1 - xvm-fencing
 Target: vm-rhel72-\d
   Level 2 - xvm-fencing
 Target: id=nodes-2
   Level 3 - xvm-fencing
 Target: id=nodes-3
   Level 3 - xvm-fencing
[vm-rhel72-1 ~] $ pcs stonith level remove 3 attrib%id=nodes-3
[vm-rhel72-1 ~] $ pcs stonith show
 xvm-fencing    (stonith:fence_xvm):    Started vm-rhel72-1
 Target: vm-rhel72-2
   Level 1 - xvm-fencing
 Target: vm-rhel72-\d
   Level 2 - xvm-fencing
 Target: id=nodes-2
   Level 3 - xvm-fencing
Comment 23 errata-xmlrpc 2017-08-01 18:22:57 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/RHBA-2017:1958