> Description of problem:

The monitor function performed automatically on every existing (even disabled) resource seems to be too agressive in terms of the outcome for the cluster. One good example of this behavior is a simple typo in one of IPsrcaddr resource's option.

I created a resource called MyTypo and intentionally specified an invalid IP address of '192.168.1.411', obviously meant as '192.168.1.41' but making a typo like this is not tha uncommon. The important part here is the --disabled flag, which makes the resource never to be actually started (as pcs adds the relevant meta-attribute in the same step as creating the resource itself):

[root@virt-042 ~]# pcs resource create MyTypo IPsrcaddr ipaddress=192.168.1.411 --disabled

One would expect the resource to be just sitting there, but instead the cluster comes up with a fencing rampage, killing nodes one by one. The only lucky node here was virt-042 which happened not to have 'ifconfig' command installed which appears to be the reason for it to be spared. This is how the cluster status looked from virt-042 shortly after adding the MyTypo resource:

[root@virt-042 ~]# pcs status
Cluster name: r7cluster
Last updated: Wed Mar 11 11:05:37 2015
Last change: Wed Mar 11 11:05:24 2015
Stack: corosync
Current DC: virt-044 (4) - partition WITHOUT quorum
Version: 1.1.12-a14efad
4 Nodes configured
2 Resources configured

Node virt-044 (4): UNCLEAN (online)
Online: [ virt-042 ]
OFFLINE: [ virt-041 virt-043 ]

Full list of resources:
 Fencing	(stonith:fence_xvm):	Stopped 
 MyTypo	(ocf::heartbeat:IPsrcaddr):	FAILED virt-044 

Failed actions:
    MyTypo_stop_0 on virt-044 'not installed' (5): call=10, status=complete, exit-reason='We are not serving [192.168.1.411], hence can not make it a preferred source address', last-rc-change='Wed Mar 11 11:05:25 2015', queued=0ms, exec=95ms
    MyTypo_stop_0 on virt-044 'not installed' (5): call=10, status=complete, exit-reason='We are not serving [192.168.1.411], hence can not make it a preferred source address', last-rc-change='Wed Mar 11 11:05:25 2015', queued=0ms, exec=95ms
    MyTypo_monitor_0 on virt-042 'not installed' (5): call=9, status=complete, exit-reason='Setup problem: couldn't find command: ifconfig', last-rc-change='Wed Mar 11 11:05:24 2015', queued=0ms, exec=35ms
    MyTypo_monitor_0 on virt-042 'not installed' (5): call=9, status=complete, exit-reason='Setup problem: couldn't find command: ifconfig', last-rc-change='Wed Mar 11 11:05:24 2015', queued=0ms, exec=35ms


I'm not arguing here with reasons why every existing resource is being constantly monitored regardless of it's target status set by the admin, but having a resource causing a killing spree due to a typo when the resource was never actually meant to be started (target-role=Stopped right from the beginning) is something I do not see as a reasonable behavior.


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

[root@virt-042 ~]# rpm -q pacemaker resource-agents pcs
pacemaker-1.1.12-22.el7.x86_64
resource-agents-3.9.5-40.el7.x86_64
pcs-0.9.137-13.el7.x86_64


> How reproducible:

Always


> Steps to Reproduce:

1. have a cluster with proper fencing set up
2. add a resource, which is both disabled and will have an issue running a monitor operation


> Actual results:

Killing spree!


> Expected results:

No fencing, and ideally no failed monitor operation at all.