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

[Ron Kerry]

Note: The bogus reporting only seems to be an issue with a live check (-L). If you check a stored 
pe-input file (even from the same time frame), it does not report these issues.



On 7/1/14, 1:30 PM, Ron Kerry wrote:
> 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
Global Product Support - SGI Federal