A relation-departed hook cannot be used by a charm to perform cleanup, as the remote service may have already run its relation-departed hook and revoked access. From the documentation, "this should be used to remove all references to the remote unit, because there's no guarantee that it's still part of the system".
The situation is worse for a peer relation. In addition to the above catch-22, the unit running the relation-departed hook has no idea if it is the unit leaving the service or if it is the remote unit leaving the service.
So as a concrete example, it is impossible for the Cassandra charm to automatically decommission a node before it is removed. The peer-relation-departed hook cannot decommission the node because the charm has no idea which unit is actually being dropped. And even if it did, the decommissioning process would fail as it takes time and the other units in the cluster will have revoked its access before it completed. Instead, the operator is required to manually decommission nodes before dropping the unit. Failing to do this requires lengthy cleanup operations, and data stored at replication factor 1 will be lost.
Before the relation-departed hooks are run, another hook needs to be run on the departing unit to provide it with the opportunity it needs. relation-departing seems the obvious choice.
Hi.
This is also issue for the percona-cluster charm which can't safely remove the unit - it should shut down mysql prior removing the unit but it can't do so as there is no way to tell on which endpoint of the relation the -departed hook is running (if it's on the unit to be removed then mysql should be stopped, but not on the other one!).
Introducing a hook that would fire before -departed, only on unit that is about to depart relation, would solve this issue. /bugs.launchpad .net/charms/ +source/ percona- cluster/ +bug/1514472)
(Here is the percona-cluster related bug: https:/