This is needed for IHA FFU. And the reason is as follows:
When we upgrade the first node of the control plane (in the 3 controller
case scenario), we create a brand new one-node cluster. Now when the
stonith location constraint for ipmi is created, it assigns a negative
score to the ipmi resource running on the single node and so it will
simply be stopped and not run at all. This creates a problem at the
end of the upgrade process for the first controller, because
the final steps that verify resources are up will fail:
fatal: [controller-0]: FAILED! => {"changed": false, "error": "Error: waiting timeout\n\nPending actions:\n\tAction 29:
stonith-fence_ipmilan-525400c4f1c1_monitor_0\ton cont roller-0\n\tAction 28: stonith-controller-0-on\ton controller-0\nError performing
operation: Timer expired\n", "msg": "Failed, to set the resource openstack-cinder-volume to the state enable", "output": "", "rc": 1}
That is because pacemaker will calculate a transition that requires a
stonith 'ON' operation which cannot happen because the stonith
resource is not running.
I've checked with Beekhof and this is a bit of a current limitation
in pacemaker when running on a single node (inability to ignore the
negative score when there is only one node). To avoid this we
only create the stonith location constraint when there is more than
one node (as output by crm_node -l)
Tested a number of times on IHA FFU successfully.
Related-Bug: #1888398
Change-Id: Iefe68c26b188922d1e8fe4cd0d24242262ee6665
7a82bae811