Red Hat Bugzilla – Bug 1261116
Allow targeting by attribute in fencing topology
Last modified: 2018-01-10 08:00:20 EST
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
Just a note the syntax is slightly changing from #1, Ken will update this bug when the new syntax is set in pacemaker.
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.
Created attachment 1230028 [details] proposed fix Tests are included in the patch. For command line tests see the pcs/test/test_stonith.py file.
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
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