Change Details

Currently, when a transition is aborted, any pending actions must complete before a new transition can be completed, since the outcome of the actions will affect the calculation. It would be computationally infeasible to calculate all possible combinations of all possible outcomes of all pending actions in order to schedule only actions that will be needed regardless of what happens. However a simpler approach would be to calculate only whether fencing is needed, since that is generally independent of pending action outcomes. Examples would be node loss or failure of an action with `on-fail` set to `fence`. The scheduler API would need a flag to request this new mode. When a transition is aborted, and actions are still pending, the controller would run the scheduler with the new flag. The resulting transition graph would either be empty or contain only fencing actions. It would need to track the progress of both transitions simultaneously. Any pending actions on a node scheduled for fencing would have to be ignored once fencing completes. The controller would run a full scheduler once the pending actions (including any fencing from the special transition) complete. See also: * [[https://issues.redhat.com/browse/RHEL-61478 | RHEL-61478]] * [[https://bugzilla.redhat.com/show_bug.cgi?id=1508723 | RHBZ#1508723]]

Currently, when a transition is aborted, any pending actions must complete before a new transition can be completed, since the outcome of the actions will affect the calculation. It would be computationally infeasible to calculate all possible combinations of all possible outcomes of all pending actions in order to schedule only actions that will be needed regardless of what happens. However a simpler approach would be to calculate only whether fencing is needed, since that is generally independent of pending action outcomes. Examples would be node loss or failure of an action with `on-fail` set to `fence`. The scheduler API would need a flag to request this new mode. When a transition is aborted, and actions are still pending, the controller would run the scheduler with the new flag. The resulting transition graph would either be empty or contain only fencing actions. It would need to track the progress of both transitions simultaneously. Any pending actions on a node scheduled for fencing would have to be ignored once fencing completes. The controller would run a full scheduler once the pending actions (including any fencing from the special transition) complete. This is closely related to T312 but for a narrower (and easier to implement) use case. See also: * [[https://issues.redhat.com/browse/RHEL-61478 | RHEL-61478]] * [[https://bugzilla.redhat.com/show_bug.cgi?id=1508723 | RHBZ#1508723]]

Currently, when a transition is aborted, any pending actions must complete before a new transition can be completed, since the outcome of the actions will affect the calculation. It would be computationally infeasible to calculate all possible combinations of all possible outcomes of all pending actions in order to schedule only actions that will be needed regardless of what happens. However a simpler approach would be to calculate only whether fencing is needed, since that is generally independent of pending action outcomes. Examples would be node loss or failure of an action with `on-fail` set to `fence`. The scheduler API would need a flag to request this new mode. When a transition is aborted, and actions are still pending, the controller would run the scheduler with the new flag. The resulting transition graph would either be empty or contain only fencing actions. It would need to track the progress of both transitions simultaneously. Any pending actions on a node scheduled for fencing would have to be ignored once fencing completes. The controller would run a full scheduler once the pending actions (including any fencing from the special transition) complete. This is closely related to T312 but for a narrower (and easier to implement) use case. See also: * [[https://issues.redhat.com/browse/RHEL-61478 | RHEL-61478]] * [[https://bugzilla.redhat.com/show_bug.cgi?id=1508723 | RHBZ#1508723]]