[Pacemaker] crm_verify reports bogus "requires fencing but fencing is disabled" notices

[Ron Kerry]

I have seen the following reporting coming out of crm_verify that is clearly misleading to a 
sysadmin. Every resource defined with this sort of start/stop operations is called out twice 
(presumably because this is a 2-node cluster)
    op start interval="0" timeout="xx" on-fail="restart" requires="fencing"
    op stop interval="0" timeout="xx" on-fail="fence"

piranha:~ # crm_verify -LVVV
   notice: unpack_config:        On loss of CCM Quorum: Ignore
   notice: unpack_operation:     DMF requires fencing but fencing is disabled
   notice: unpack_operation:     CXFS requires fencing but fencing is disabled
   notice: unpack_operation:     IP requires fencing but fencing is disabled
   notice: unpack_operation:     IP2 requires fencing but fencing is disabled
   notice: unpack_operation:     NFS requires fencing but fencing is disabled
   notice: unpack_operation:     DMFSOAP requires fencing but fencing is disabled
   notice: unpack_operation:     DMFMAN requires fencing but fencing is disabled
   notice: unpack_operation:     OV requires fencing but fencing is disabled
   notice: unpack_operation:     CXFS requires fencing but fencing is disabled
   notice: unpack_operation:     IP requires fencing but fencing is disabled
   notice: unpack_operation:     IP2 requires fencing but fencing is disabled
   notice: unpack_operation:     OV requires fencing but fencing is disabled
   notice: unpack_operation:     DMF requires fencing but fencing is disabled
   notice: unpack_operation:     NFS requires fencing but fencing is disabled
   notice: unpack_operation:     DMFMAN requires fencing but fencing is disabled
   notice: unpack_operation:     DMFSOAP requires fencing but fencing is disabled

Fencing is enabled and perfectly functioning in this cluster.

piranha:~ # crm status ops
Last updated: Tue Jul  1 12:22:53 2014
Last change: Tue Jul  1 10:30:46 2014 by hacluster via crmd on piranha
Stack: classic openais (with plugin)
Current DC: piranha - partition with quorum
Version: 1.1.10-f3eeaf4
2 Nodes configured, 2 expected votes
11 Resources configured


Online: [ piranha pirarucu ]

  STONITH-piranha	(stonith:external/ipmi):	Started pirarucu
  STONITH-pirarucu	(stonith:external/ipmi):	Started piranha
  NOTIFY	(ocf::heartbeat:MailTo):	Started piranha
  Resource Group: DMF-GROUP
      CXFS	(ocf::sgi:cxfs):	Started piranha
      IP	(ocf::heartbeat:IPaddr2):	Started piranha
      IP2	(ocf::heartbeat:IPaddr2):	Started piranha
      OV	(ocf::sgi:openvault):	Started piranha
      DMF	(ocf::sgi:dmf):	Started piranha
      NFS	(ocf::heartbeat:nfsserver):	Started piranha
      DMFMAN	(ocf::sgi:dmfman):	Started piranha
      DMFSOAP	(ocf::sgi:dmfsoap):	Started piranha

Operations:
* Node piranha:
    STONITH-pirarucu: migration-threshold=1000000
     + (47) start: rc=0 (ok)
     + (50) monitor: interval=300000ms rc=0 (ok)
    NOTIFY: migration-threshold=1000000
     + (48) start: rc=0 (ok)
    DMF: migration-threshold=1
     + (56) start: rc=0 (ok)
     + (57) monitor: interval=120000ms rc=0 (ok)
    CXFS: migration-threshold=1
     + (49) start: rc=0 (ok)
     + (51) monitor: interval=120000ms rc=0 (ok)
    IP: migration-threshold=1
     + (52) start: rc=0 (ok)
    IP2: migration-threshold=1
     + (53) start: rc=0 (ok)
    NFS: migration-threshold=1
     + (58) start: rc=0 (ok)
     + (59) monitor: interval=120000ms rc=0 (ok)
    DMFMAN: migration-threshold=100
     + (60) start: rc=0 (ok)
    OV: migration-threshold=1
     + (54) start: rc=0 (ok)
     + (55) monitor: interval=120000ms rc=0 (ok)
    DMFSOAP: migration-threshold=100
     + (66) probe: rc=0 (ok)
* Node pirarucu:
    STONITH-piranha: migration-threshold=1000000
     + (47) start: rc=0 (ok)
     + (48) monitor: interval=300000ms rc=0 (ok)


primitive STONITH-piranha stonith:external/ipmi \
         op monitor interval="0" timeout="60s" \
         op monitor interval="300s" on-fail="restart" timeout="60s" \
         op start interval="0" on-fail="restart" timeout="60s" \
         params hostname="piranha" ipaddr="128.162.245.136" userid="admin" passwd="admin" 
interface="lan"
primitive STONITH-pirarucu stonith:external/ipmi \
         op monitor interval="0" timeout="60s" \
         op monitor interval="300s" on-fail="restart" timeout="60s" \
         op start interval="0" on-fail="restart" timeout="60s" \
         params hostname="pirarucu" ipaddr="128.162.245.137" userid="admin" passwd="admin" 
interface="lan"
location STONITH-piranha-LOCATION STONITH-piranha -inf: piranha
location STONITH-pirarucu-LOCATION STONITH-pirarucu -inf: pirarucu

property $id="cib-bootstrap-options" \
         no-quorum-policy="ignore" \
         pe-input-series-max="99" \
         pe-warn-series-max="99" \
         pe-error-series-max="99" \
         stonith-enabled="true" \
         dc-version="1.1.10-f3eeaf4" \
         cluster-infrastructure="classic openais (with plugin)" \
         expected-quorum-votes="2" \
         last-lrm-refresh="1404228646"


The above is from a SLES11SP3-HAE cluster running pacemkaer 1.1.10, but I observe the exact same 
behavior on a RHEL65-HA cluster also running pacemaker 1.1.10 ("1.1.10-14.el6_5.3-368c726").

-- 

Ron Kerry         rkerry at sgi.com