Add ability to run observed event ONLY on Juju leader

Reasoning

It’s very common to have the first part of any event handler to be if not self.charm.unit.is_leader(): return Usually this is because the handler sets app data, but there can be other reasons why you might want to only run on leader.

Although it’s small, it would be nice to have some functionality to avoid this.

(IDEA) - Maybe a decorator?

I have a pretty crappy decorator that I wrote that looks roughly like the following:

def leader_check(func: Callable) -> Any:
    def check_unit_leader(*args, **kwargs):
        if not kwargs["event"].unit.is_leader():
            return
        else:
            return func(*args, **kwargs)

    return check_unit_leader

@leader_check
def _on_relation_joined(self, event):
    set_app_data()

but that doesn’t run on every event. It would be nice if we could reduce the leader-checks overall in some way.

[PietroPasotti]

Something I’d not be ‘too opposed to’ is this pattern:

# (in __init__):
if self.unit.is_leader():
    self.framework.observe(foo, self._foo_if_leader)
else: 
    self.framework.observe(foo, self._foo_if_not_leader)

# regardless:
self.framework.observe(bar, self._on_bar)

If you have some events (E.g. relation stuff) you really only care about if you’re a leader…

Regarding the fact that leader/nonleader is a common branching point in charms, yeah… I had a half baked design on ‘branching charms’ which I might need to revisit…

[marcoppenheimer]

The event.unit attribute (which is only on relation events) refers to the remote application unit that triggered the event. You would probably want kwargs["event"].framework.model.unit.is_leader(). @PietroPasotti and others have spent some time thinking about similar needs/issues. We’ll keep this suggestion on our radar - it’s a good thought.

Yeah it was a crappy solution, decorator probably wouldn’t work, but overall I hope the intent was clear.