<div dir="ltr">Hi Ken,<div><br></div><div>I managed to reproduce this on a simplified version of the cluster, and on Pacemaker 1.1.15, 1.1.16, as well as 1.1.18-rc1</div><div><br></div><div>The steps to create the cluster are:</div><div><br></div><div><div>pcs property set stonith-enabled=false</div><div>pcs property set placement-strategy=balanced</div><div><br></div><div>pcs node utilization vm1 cpu=100</div><div>pcs node utilization vm2 cpu=100</div><div>pcs node utilization vm3 cpu=100</div><div><br></div><div>pcs property set maintenance-mode=true</div><div><br></div><div>pcs resource create sv-fencer ocf:pacemaker:Dummy</div><div><br></div><div>pcs resource create sv ocf:pacemaker:Dummy clone notify=false</div><div>pcs resource create std ocf:pacemaker:Dummy meta resource-stickiness=100</div><div><br></div><div>pcs resource create partition1 ocf:pacemaker:Dummy meta resource-stickiness=100</div><div>pcs resource create partition2 ocf:pacemaker:Dummy meta resource-stickiness=100</div><div>pcs resource create partition3 ocf:pacemaker:Dummy meta resource-stickiness=100</div><div><br></div><div>pcs resource utilization partition1 cpu=5</div><div>pcs resource utilization partition2 cpu=5</div><div>pcs resource utilization partition3 cpu=5</div><div><br></div><div>pcs constraint colocation add std with sv-clone INFINITY</div><div>pcs constraint colocation add partition1 with sv-clone INFINITY</div><div>pcs constraint colocation add partition2 with sv-clone INFINITY</div><div>pcs constraint colocation add partition3 with sv-clone INFINITY</div><div><br></div><div>pcs property set maintenance-mode=false</div></div><div> </div><div><br></div><div>I can then reproduce the issues in the following way:</div><div><br></div><div><div>$ pcs resource</div><div> sv-fencer      (ocf::pacemaker:Dummy): Started vm1</div><div> Clone Set: sv-clone [sv]</div><div>     Started: [ vm1 vm2 vm3 ]</div><div> std    (ocf::pacemaker:Dummy): Started vm2</div><div> partition1     (ocf::pacemaker:Dummy): Started vm3</div><div> partition2     (ocf::pacemaker:Dummy): Started vm1</div><div> partition3     (ocf::pacemaker:Dummy): Started vm2</div><div><br></div><div><div>$ pcs cluster standby vm3</div><div><br></div><div># Check that all resources have moved off vm3</div><div>$ pcs resource</div><div> sv-fencer      (ocf::pacemaker:Dummy): Started vm1</div><div> Clone Set: sv-clone [sv]</div><div>     Started: [ vm1 vm2 ]</div><div>     Stopped: [ vm3 ]</div><div> std    (ocf::pacemaker:Dummy): Started vm2</div><div> partition1     (ocf::pacemaker:Dummy): Started vm1</div><div> partition2     (ocf::pacemaker:Dummy): Started vm1</div><div> partition3     (ocf::pacemaker:Dummy): Started vm2</div><div><br></div><div># Wait for any outstanding actions to complete.</div><div>$ crm_resource --wait --timeout 300<br></div><div>Pending actions:</div><div>        Action 22: sv-fencer_monitor_10000      on vm2</div><div>        Action 21: sv-fencer_start_0    on vm2</div><div>        Action 20: sv-fencer_stop_0     on vm1</div><div>Error performing operation: Timer expired</div></div><div><br></div><div># Check the resources again - sv-fencer is still on vm1</div><div><div>$ pcs resource<br></div><div> sv-fencer      (ocf::pacemaker:Dummy): Started vm1</div><div> Clone Set: sv-clone [sv]</div><div>     Started: [ vm1 vm2 ]</div><div>     Stopped: [ vm3 ]</div><div> std    (ocf::pacemaker:Dummy): Started vm2</div><div> partition1     (ocf::pacemaker:Dummy): Started vm1</div><div> partition2     (ocf::pacemaker:Dummy): Started vm1</div><div> partition3     (ocf::pacemaker:Dummy): Started vm2</div></div><div><br></div><div># Perform a random update to the CIB.</div><div>$ pcs resource update std op monitor interval=20 timeout=20<br></div><div><br></div><div># Check resource status again - sv_fencer has now moved to vm2 (the action crm_resource was waiting for)</div><div><div>$ pcs resource</div><div> sv-fencer      (ocf::pacemaker:Dummy): Started vm2  <<<============</div><div> Clone Set: sv-clone [sv]</div><div>     Started: [ vm1 vm2 ]</div><div>     Stopped: [ vm3 ]</div><div> std    (ocf::pacemaker:Dummy): Started vm2</div><div> partition1     (ocf::pacemaker:Dummy): Started vm1</div><div> partition2     (ocf::pacemaker:Dummy): Started vm1</div><div> partition3     (ocf::pacemaker:Dummy): Started vm2</div></div><div><br></div><div class="gmail_extra">I do not get the problem if I:</div></div><div class="gmail_extra">1) remove the "std" resource; or</div><div class="gmail_extra">2) remove the co-location constraints; or</div><div class="gmail_extra">3) remove the utilization attributes for the partition resources.</div><div class="gmail_extra"><br></div><div class="gmail_extra">In these cases the sv-fencer resource is happy to stay on vm1, and crm_resource --wait returns immediately.</div><div class="gmail_extra"><br></div><div class="gmail_extra">It looks like the pcs cluster standby call is creating/registering the actions to move the sv-fencer resource to vm2, but it doesn't include it in the cluster transition.  When the CIB is later updated by something else, the action is included in that transition.</div><div class="gmail_extra"><br></div><div class="gmail_extra"><br></div><div class="gmail_extra">Regards,</div><div class="gmail_extra">Leon</div><div class="gmail_extra"><br></div></div>