Challenge: get rid of the _common_exit_hook pattern, with minimal changes to tests.
Top score: for whoever introduces a repeatable pattern.
Negative score: for transforming into explosive spaghetti.
Please link you PR to this issue.
Optional constraints
Feel free to use all/some/none:
Only top-level event hooks allowed to change unit status
Do not use StoredState
Construct provider/consumer instances only if the respective relation is formed
Do not rely on update-status to finish the charm's startup sequence
Past attempts
Deferring decorators
@defer_unless(network_ready, WaitingStatus("Waiting for ip address"))
def _on_alertmanager_pebble_ready(self, event: ops.charm.PebbleReadyEvent):
# ...
@defer_unless(network_ready, WaitingStatus("Waiting for ip address"))
@skip_unless(config_valid, BlockedStatus("PagerDuty service key missing"))
def _on_config_changed(self, event: ops.charm.ConfigChangedEvent):
# ...
The underlying assumptions were:
Deferral/skip is decideable via a boolean callable (e.g. network_ready) at event entry
The boolean callables are always of the form check(charm, event)
The @defer_unless/@skip_unless decorator usage can be limited to event hooks only
Rely on update-status
In all event hooks, use defer if a precondition is not met. This means that the charm may end up in stagnation until the next update-status. If the default update-status hook interval of 5min is kept by the user, then relying on update-status is not too bad, but if the user creates a controller or model with a default of, say, 60 min, then it may be too long.
Challenge: get rid of the
_common_exit_hookpattern, with minimal changes to tests.Top score: for whoever introduces a repeatable pattern. Negative score: for transforming into explosive spaghetti.
Please link you PR to this issue.
Optional constraints
Feel free to use all/some/none:
Past attempts
Deferring decorators
The underlying assumptions were:
network_ready) at event entrycheck(charm, event)@defer_unless/@skip_unlessdecorator usage can be limited to event hooks onlyRely on
update-statusIn all event hooks, use
deferif a precondition is not met. This means that the charm may end up in stagnation until the next update-status. If the default update-status hook interval of 5min is kept by the user, then relying on update-status is not too bad, but if the user creates a controller or model with a default of, say, 60 min, then it may be too long.