Event > List of events > Lifecycle events
The bulk of the events a charm will see during its lifetime are “lifecycle events”: broadly defined as: events that don’t fit into any other specific category.
Contents:
Complete list of lifecycle events
start: fired as soon as the unit initialization is complete.config-changed: fired whenever the cloud admin changes the charm configuration *.install: fired when juju is done provisioning the unit.<container>-pebble-ready: fired on kubernetes charms when the requested container is ready.<container>-pebble-custom-notice: fired when a Pebble custom notice is triggered.<container>-pebble-check-failed: fired when a Pebble check passes the failure threshold (in Juju 3.6 and above)<container>-pebble-check-recovered: fired when a Pebble check passes after previously reaching the failure threshold (in Juju 3.6 and above)leader-elected: fired on the new leader when juju elects one.leader-settings-changed: fired on all follower units when a new leader is chosen.pre-series-upgrade: fired before the series upgrade takes place.post-series-upgrade: fired after the series upgrade has taken place.stop: fired before the unit begins deprovisioning.remove: fired just before the unit is deprovisioned.update-status: fired automatically at regular intervals by juju.upgrade-charm: fired when the cloud admin upgrades the charm.collect-metrics: (deprecated, will be removed soon)
Lifecycle event triggers
All lifecycle events are triggered in a predictable pattern following a specific action by the administrator (with the exception of update-status, which triggers on an interval, and Kubernetes container events, such as <container >-pebble-ready, which can occur at any time). For example:
| Scenario | Example Command | Resulting Events |
|---|---|---|
| Deploy | juju deploy ./hello-operator.charm |
install -> config-changed -> start -> <container>-pebble-ready |
| Scale | juju add-unit -n 2 hello-operator |
install -> config-changed -> start -> <container>-pebble-ready |
| Configure | juju config hello-operator thing=foo |
config-changed |
| Upgrade | juju upgrade-charm hello-operator |
upgrade-charm -> config-changed -> <container>-pebble-ready |
| Remove | juju remove-application hello-operator |
stop -> remove |
Exception to the “all lifecycle events are fired in a predictable pattern following cloud admin actions” rule is <container>-pebble-ready. As kubernetes pods can churn autonomously (outside of juju’s control), it can happen that the container comes and goes at unpredictable times. When that happens, the charm will receive again <container>-pebble-ready. See the page on pebble-ready for more details.
Lifecycle events in Ops
In ops, all lifecycle events are accessible via CharmBase’s on attribute.
So you typically want to observe these events by doing:
# in MyCharm(CharmBase) __init__():
self.framework.observe(self.on.start, self._on_start)
self.framework.observe(self.on.install, self._on_install)
...