Pacemaker creates a unit override for systemd resources when starting them, and removes the override when stopping them. It has to reload systemd to make it take effect.
If there are multiple systemd resources starting or stopping in the same transition, systemd has to be reloaded for each one, which can add significant delays unnecessarily.
It would be better to create all new overrides needed and reload systemd once at the beginning of a transition, and remove all old overrides and reload systemd once at the end of a transition.
One possibility would be for the scheduler would add new `pcmk__cluster_graph_action` ops for creating/removing overrides that the controller would forward to the executor. The main complication would be aborted transitions. If a transition is aborted after overrides have been created, it's possible the related starts would no longer be needed, and the overrides would incorrectly remain. Similarly, if a transition is aborted after systemd resources have stopped but before the overrides have been removed, the scheduler would have no way of knowing the overrides still need to be removed. A possible way around that would be to record overrides and systemd reloads in the CIB resource history.
Managing overrides in the executor instead is not practical since the executor has no concept of a transition.
Alternatively, the controller could manage overrides independently of the scheduler. The controller could scan each new transition graph for systemd start actions, remember them, and send the executor a single new command to create all the overrides and reload systemd before executing the first start. Stop actions would be similar for removing overrides after the last stop. As each systemd start or stop is executed, the controller would update its knowledge of what needs to be done. When a transition is aborted, it would check that state and send the executor any command necessary.