From operations perspective the unit-enable-auto-restarts seems to introduce more overhead to manage big clouds via actions to perform "Set unit-enable-auto-restarts=False via action for existing units"
Also treating the enable-auto-restarts as an unit level config may produce mixed environments where units allowing restarts and unit not allowing restarts coexist and if the operator forgets to set unit-enable-auto-restarts=False for an unit this may cause outages impacting customers workloads.
Ideally deferred events should ensure the following use cases:
- first installation is not broken by the deferred events
- deferred events don't prevent unit to be rebooted and allow to the unit to run all hooks and restarts they need when booting to get into a working state.
- if a queued deferred event needs to run to ensure that an unit is fully working, the unit turns into a blocked state until the deferred event is not executed via action.
From operations perspective the unit-enable- auto-restarts seems to introduce more overhead to manage big clouds via actions to perform "Set unit-enable- auto-restarts= False via action for existing units"
Also treating the enable- auto-restarts as an unit level config may produce mixed environments where units allowing restarts and unit not allowing restarts coexist and if the operator forgets to set unit-enable- auto-restarts= False for an unit this may cause outages impacting customers workloads.
Ideally deferred events should ensure the following use cases:
- first installation is not broken by the deferred events
- deferred events don't prevent unit to be rebooted and allow to the unit to run all hooks and restarts they need when booting to get into a working state.
- if a queued deferred event needs to run to ensure that an unit is fully working, the unit turns into a blocked state until the deferred event is not executed via action.