actually, toggling vmr-132-5 in the following simpler setup produces the same service flap as before.
Cluster Name: Corosync Nodes: 192.168.132.5 192.168.132.4 192.168.132.3 Pacemaker Nodes: vmr-132-3 vmr-132-4 vmr-132-5 Resources: Resource: MsgBB-Active (class=ocf provider=solace type=MsgBB-Active) Meta Attrs: migration-threshold=2 failure-timeout=1s Operations: start interval=0s timeout=2 (MsgBB-Active-start-interval-0s) stop interval=0s timeout=2 (MsgBB-Active-stop-interval-0s) monitor interval=1s (MsgBB-Active-monitor-interval-1s) Stonith Devices: Fencing Levels: Location Constraints: Resource: MsgBB-Active Enabled on: vmr-132-3 (score:100) (id:AUTO-REVERT) Ordering Constraints: Colocation Constraints: Resources Defaults: No defaults set Operations Defaults: No defaults set Cluster Properties: cluster-infrastructure: corosync cluster-recheck-interval: 1s dc-version: 1.1.13-10.el7_2.2-44eb2dd have-watchdog: false start-failure-is-fatal: false stonith-enabled: false MsgBB-Active is a dummy resource that simply returns OCF_SUCCESS on every operation and logs to a file. _______________________________________________ Users mailing list: Users@clusterlabs.org http://clusterlabs.org/mailman/listinfo/users Project Home: http://www.clusterlabs.org Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf Bugs: http://bugs.clusterlabs.org