Event 'remove'

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.