Event > List of events > Lifecycle events >
removeSource:
ops.RemoveEvent
The remove event is emitted only once per unit: when the Juju controller is ready to remove the unit completely. The stop event is emitted prior to this, and all necessary steps for handling removal should be handled there.
Contents:
Emission sequence
The remove event is the last event a unit will ever see before going down, right after stop. It is exclusively fired when the unit is in the Teardown phase.
Handlers for this event should ensure that the workload is ‘gracefully’ shutdown.
Note that by the time
removeis fired, storage, relations and all charm resources will likely no longer be available. If you need to cleanup any of those, listen to*-relation-brokenor*-storage-detachinginstead.
Triggers
On kubernetes charms, the remove event will occur on pod churn, when the unit dies. On machine charms, the stop event will be fired when a unit is put down.
| Scenario | Example Command | Resulting Events |
|---|---|---|
| Remove unit |
juju remove-unit foo/0 (on machine) or juju remove-unit --num-units 1 foo (on k8s) |
stop -> [relation/storage teardown] -> remove |
Of course, removing an application altogether will result in these events firing on all units.
If the unit has any relations active or any storage attached at the time the removal occurs, these will be cleaned up (in no specific order) between stop and remove. This means the unit will receive stop -> (*-relation-broken | *-storage-detaching) -> remove.
Observing this event in Ops
In ops, you can observe the remove event like you would any other:
self.framework.observe(self.on.remove, self._on_remove)
The remove event object does not expose any specific attributes.