Comment 13 for bug 1417874

The problem would still remain: when unit is being removed, juju fires the -departed hook, but we don't know, when inside the hook, is the hook running on the unit that's being removed, or on the unit that's remaining.

If you have two units deployed, say, percona-cluster. When you remove one of the units (say, percona-cluster/0) here is what happens:

1a. -relation-departed hook is run in percona-cluster/0
1b. -relation-departed hook is run in percona-cluster/1

2.-relation-broken hook is run in percona-cluster/0

Now, this creates the issue. When -relation-departed hook is run on both units there is no way for the hook code to know if it's running on the unit that's parting or on the unit that's remaining. Therefore it can't politely stop mysqld service. Currently if you just 'juju remove-unit', and get rid of percona-cluster/1, percona-cluster/0's mysqld will switch to 'degraded' state and will not allow querying data.

A "-relation-departing" hook would solve that issue (or the environment variable, or any other mechanism that would allow hook that is being run to know if it's run on departing unit or not).

(In this particular example with percona-cluster the workaround is quite simple - operator would, prior issuing 'juju remove-unit', ssh into the unit that is to be removed and manually issue a clean shutdown of mysql service. After mysql stops there operator can utilize 'juju remove-unit' to get rid of the unit completely. However, having a separate hook would, imho, greatly simplify unit removal).