Event > List of events > Lifecycle events >
remove
Source:
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
remove
is fired, storage, relations and all charm resources will likely no longer be available. If you need to cleanup any of those, listen to*-relation-broken
or*-storage-detaching
instead.
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.