Comment 7 for bug 1915512

The leader unit octavia/0 also has the env variable JUJU_DEPARTING_UNIT=octavia/5 when running 'juju remove-unit octavia/5'

$ juju debug-hooks octavia/0 cluster-relation-joined cluster-relation-changed cluster-relation-broken cluster-relation-departe
...
root@juju-7781dd-octavia-8:/var/lib/juju/agents/unit-octavia-0/charm# set |grep JUJU |grep 'octavia\/'
JUJU_CONTEXT_ID=octavia/0-cluster-relation-departed-3345772523281443755
JUJU_DEPARTING_UNIT=octavia/5
JUJU_REMOTE_UNIT=octavia/5
JUJU_UNIT_NAME=octavia/0

So I implemented patchset 4 [1] to avoid passing departing_unit_name from deprted unit to leader unit [2], but my self-test shows the following code has never been run

reactive.flags.register_trigger(
    when_not='cluster.connected', set_flag='unit.departed')

...
@reactive.when('unit.departed')
def update_controller_ip_port_list():
    ...

because I can always see the flag cluster.connected

$ juju run --unit octavia/0 -- 'charms.reactive -p get_flags' |grep cluster
 'charms.openstack.do-default-cluster.available',
 'cluster.available',
 'cluster.connected',

After experiencing these setbacks, I feel that it should be a good choice to use 'action' to implement these logic. Hope to hear your thoughts.

[1] https://review.opendev.org/c/openstack/charm-octavia/+/787700/4/src/reactive/octavia_handlers.py#47
[2] https://bugs.launchpad.net/charm-octavia/+bug/1915512/comments/6