Lifecycle events

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

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)
...

Is “PebbleReady” considered a life-cycle event?

Sure is! I didn’t document this here, as I was trying to cover only those events that all charms would see :slight_smile: I can make adjustments if that’s misleading! :slight_smile:

Hello Jon!

For a side-car charm would be great if we have the table with the lifecycles events including the Pebble ones.
I am no sure if this information should be in this section, or maybe in the Running Workloads?

Hi, here are some thoughts on how we can improve this page along with some questions that came up while reading it.

  • The config-change event seems overloaded. Is there a way to find out what caused this event to trigger?

  • “Invocations of associated callbacks should be idempotent and should not make changes to the environment, or restart services, unless there is a material change to the charm’s configuration.” This sentence needs more explanation, especially the unless part. What is a material change?

  • Are there any side effects in deferring the upgrade-charm event?

  • Should we discuss the “Remove” event? Based on the table “Example Lifecycles” there should be one such event.

  • Charm authors should assume that anything and everything could change with config-change. Pebble is really a sidecar, but when healthchecks are introduced, a failing check may lead to killing a pod for a Charmed Operator which would break any “smarter” configuration. In keeping with idempotency, a config-changed event should assume that the entire application configuration should be re-written from scratch.

  • Updated with a couple of examples for what a “material change” may be.

  • “Remove” seems to be covered by “stop” to me.

@tmihoc - This documentation is not complete either. @jnsgruk is missing alot of events/hooks like, storage-attached, storage-departed, etc.

Having complete documentation is what you taught me from the masterful workshop =)

1 Like

Does the start hook fire after a machine reboots?

What are the sequence of events that happens when a machine comes back after a reboot?

probably too late to be useful, but I wrote a little tool to see in real-time which events are fired on which unit. can be useful to see for yourself what event sequence occurs.

Try jhack utils tail name-of-unit/0 https://github.com/PietroPasotti/jhack

Is config-changed fired after a juju attach-resource? Or there are other hooks as well, like upgrade?