Event > List of events > Lifecycle events >
startSource:
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 foojuju 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.