Change Details

In this scenario: * A cluster has a group with multiple members, and a primitive ordered after the group * An internal group member fails and is recovered * The failure is cleaned The clean-up erases the history of the internal group member, which causes the scheduler to treat it as Stopped and schedule a probe of it along with recovery of all later group members and the primitive (since they are all ordered after the previously failed member). When the probe returns OK, the transition will be aborted and the recoveries should be avoided. However currently, the scheduler will not order the stop of the primitive after the probe of the previously failed member. Thus it gets recovered even if the probe finds the member OK.

In this scenario: * A cluster has a group with multiple members, and a primitive ordered after the group * An internal group member fails and is recovered * The failure is cleaned The clean-up erases the history of the internal group member, which causes the scheduler to treat it as Stopped and schedule a probe of it along with recovery of all later group members and the primitive (since they are all ordered after the previously failed member). When the probe returns OK, the transition will be aborted and the recoveries should be avoided. However currently, the scheduler will not order the stop of the primitive after the probe of the previously failed member. Thus it gets recovered even if the probe finds the member OK. As another example, cleaning up a failed stop action can lead to resource being multiply active: * [[https://bugs.clusterlabs.org/show_bug.cgi?id=5300 | CLBZ#5300]]

In this scenario: * A cluster has a group with multiple members, and a primitive ordered after the group * An internal group member fails and is recovered * The failure is cleaned The clean-up erases the history of the internal group member, which causes the scheduler to treat it as Stopped and schedule a probe of it along with recovery of all later group members and the primitive (since they are all ordered after the previously failed member). When the probe returns OK, the transition will be aborted and the recoveries should be avoided. However currently, the scheduler will not order the stop of the primitive after the probe of the previously failed member. Thus it gets recovered even if the probe finds the member OK. As another example, cleaning up a failed stop action can lead to resource being multiply active: * [[https://bugs.clusterlabs.org/show_bug.cgi?id=5300 | CLBZ#5300]]