Description of problem: Ordering constraints of the form "stop A then stop B" with kind=Mandatory (the default) are treated as kind=Optional. It does seem to act like an Optional constraint rather than being ignored completely. I used a modified ocf:heartbeat:Dummy resource agent with a 5-second sleep in the stop operation for the dummy_stop_delay resource below. [root@fastvm-rhel-8-0-23 ~]# pcs constraint order Ordering Constraints: stop dummy_stop_delay then stop dummy2 (kind:Mandatory) When I banned dummy2, dummy_stop_delay remained online. However, when I placed the node in standby (so that both resources would be scheduled to stop), dummy2 did not initiate its stop operation until after dummy_stop_delay finished stopping. May 26 13:15:22 fastvm-rhel-8-0-23 pacemaker-controld[1811]: notice: Initiating stop operation dummy_stop_delay_stop_0 locally on fastvm-rhel-8-0-23 May 26 13:15:27 fastvm-rhel-8-0-23 pacemaker-controld[1811]: notice: Initiating stop operation dummy2_stop_0 locally on fastvm-rhel-8-0-23 ----- Version-Release number of selected component (if applicable): pacemaker-2.0.2-3.el8_1.2.x86_64 ----- How reproducible: Always ----- Steps to Reproduce: 1. Create a mandatory stop ordering constraint of the form "stop rsc_A then stop rsc_B". 2. Force rsc_B to stop (e.g., by banning it). ----- Actual results: rsc_A remains running. ----- Expected results: rsc_A stops before rsc_B. ----- Additional info: https://bugs.clusterlabs.org/show_bug.cgi?id=5416