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

[Andrew Beekhof]

Can you send us the 'cibadmin -Ql' output?

On 2 Jul 2014, at 3:30 am, Ron Kerry <rkerry at sgi.com> 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
> 
> 
> _______________________________________________
> Pacemaker mailing list: Pacemaker at oss.clusterlabs.org
> http://oss.clusterlabs.org/mailman/listinfo/pacemaker
> 
> Project Home: http://www.clusterlabs.org
> Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf
> Bugs: http://bugs.clusterlabs.org

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 841 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <https://lists.clusterlabs.org/pipermail/pacemaker/attachments/20140702/b1085581/attachment-0003.sig>