I imagine many aspects of charming would become easier if we had the following events:
Emitted by a mechanism similar to pebble checks.
Emitted after “relation broken” when the remote (stale) data is no longer visible.
Emitted once after install/upgrade when the app has no more pending changes.
All intermediate events would be dropped. Only after “startup complete” a charm would start seeing any new events.
Thanks for your suggestions @sed-i.
workload-ready is an interesting idea. This could be challenging to implement because what it means depends on the workload, which is different for each charm. Maybe this is related to the upcoming Pebble notices feature - @benhoyt?
relation-gone: we already have relation-departed and relation-broken - how would this be different?
startup-complete: again, we already have the start event (or upgrade-charm, or post-series-upgrade). How would this be different?
TLDR: departed and broken don’t guarantee that the relation data is wiped, so you might process a relation-broken but the relation and its data are still there, forcing the charm to take event-semantics-aware-codepaths instead of blindly (and simply) running code that looks at the current state and determines what to do.
I think what he’s proposing is to remove all ‘startup sequence’ events and replace them with a single one. Most of our charms don’t quite care about the difference between start/install/leader-elected and would appreciate being notified once when ‘all is ready’.
Not sure I see the benefit of this though, because indeed, we can just listen to ‘start’ and ignore the others? And, for most of our charms, the ‘real’ condition at which all is ready is when ‘pebble-ready’ fires, but that can happen at any time.
Hi @barrettj12,
Yes, I think this is exactly pebble notices.
So if juju/2024583 is fixed per request, then we won’t need relation-gone. But if relation-broken remains as-is (as Pietro described) then it would be nice CRITICAL to have yet another event, in which we’re guaranteed no stale data is visible.
The problem with start is that it is useless on its own. Same for pebble-ready: Both could be emitted at any order, requiring a can_connect check + repeating the same logic.
Workload ready
Yes, I think this is exactly pebble notices.
This only works if Pebble is in the mix (e.g. k8s based charms). If you are running a machine charm, the pebble notices is currently insufficient and would require other techniques to have this work. I recognize that this is potentially future scope, but I’m mentioning this explicitly for reasons.
One option would be to add hooks to a systemd service override and supply the necessary Exec scripts, e.g.
[service]
ExecStartPost=/usr/bin/juju-exec <unit_name>/<unit_num> -- JUJU_DISPATCH_PATH=hooks/my-custom-event ./dispatch
However, these are not necessarily the same as the Pebble Notices since Pebble offers these notices for events that happen within the Pebble system (e.g. service restart events, etc). This would likely involve integrating Pebble in a similar manner to the k8s charms on Machine charms (potentially where the containers are snaps).
This comment may seem orthogonal, but I do want to call out that there is an inconsistency between k8s and machine charms with these Pebble notices and offer a less-than-ideal alternative.
Yes, the Workload Ready could be handled with Pebble Notices “client” or custom events, which I will be working on later this cycle. However, @billy-olsen’s right that this would currently only apply for Pebble-based charms (K8s charms).
I thought eventually all charms would be pebble’d
Yes, that’s a good point. It’s definitely a long-term goal to use Pebble for non-K8s workloads too, but there are no concrete plans or timeline for that yet.