Event 'start'

doc
,
1

Event > List of events > Lifecycle events > start

Source: ops.StartEvent

This document describes the start event.

“Start” is the point where a Unit agent starts to join its relations and can respond to commands like juju run.

Contents:

Emission sequence

The start event is triggered on each starting unit immediately after the first config-changed event. Callback methods bound to the event should be used to ensure that the charm’s software is in a running state. Note that the charm’s software should be configured to persist in a started state without further intervention from Juju or an administrator.

Also, on kubernetes charms, whenever a unit’s pod churns, start will be fired again on that unit.

Scenario Example Command Resulting Events
Create unit juju deploy foo
juju add-unit foo 		install -> config-changed -> start
(k8s only) pod churn kubectl delete pod -n model-name app-name-0 stop -> upgrade-charm -> config-changed -> start
Cluster reboot microk8s stop; microk8s start start
Upgrade application juju stop -> upgrade-charm -> config-changed -> start

In kubernetes sidecar charms, Juju provides no ordering guarantees regarding start and *-pebble-ready.

Observing this event in Ops

In ops, you can observe this event like you would any other:

# in MyCharm.__init__
self.framework.observe(self.on.start, self._on_start)

The start event object does not expose any specific attributes.

2
3

Might be worthwhile to specifically mention:

  • if we do or do not see start after upgrade, kubectl delete pod, scale-application.
  • yes/no emission order guarantees with pebble-ready
1 Like
4

@sed-i could you clarify the first point? What do you mean?

RE the second point, AFAIK there’s no order guarantee. will add a note on that.

1 Like
5

I meant that we may want to explicitly mention that start is always emitted as part of:

  1. upgrade (will see as many start events emitted as there are units).
  2. manual pod churn with kubectl delete
  3. scale-application, i.e. that “start”, like all events, is per unit, not per app.
1 Like
6

Also should probably mention that start doesn’t say anything about the workload being ready.

1 Like
7
8

Could the “Emission sequence” section be updated to mention that if a workload container is restarted without the charm container being restarted on k8s charms you will get a pebble-ready event but nothing else?