Warn that model.unit.is_leader() can raise an exception

We should add a note that the is_leader() method can return an exception. is_leader() is called when a charm is attempting to determine if it will be able to invoke hook tools that are restricted to leaders, presumably to avoid the possibility of exceptions.

https://github.com/canonical/operator/blob/ccf1dce276141d1e8641d63382bb6c3055eee731/ops/model.py#L182-L184

I would personally be more comfortable with logging the problem at WARN level and returning False or None if it’s called in the context of a remote application.

[timClicks]

I understand the rationale here. @jameinel’s example makes it clear that charm authors can’t stumble into the exception, and thus the error state. But…

An unhandled exception could be very costly to someone deploying a charm. A non-zero exit is very difficult to recover from in a live model. Unless you are writing a charm, the error state is very difficult to resolve. Accordingly, we should only raise exceptions if we genuinely believe that we can’t proceed.

In this case, is_leader() could easily return False in cases where its argument is invalid. Callers would be well behaved and the model would progress happily.

So yes, raising an exception is the perfect thing to do from a Python-perspective. But charms operate in a much different context to most Python programs.

[jameinel]

is leader does return a boolean.

It just raises an exception if you do:

unit = self.model.get_unit(‘other-app/0’) unit.is_leader()

self.unit.is_leader()

just returns a boolean.

On Mon, May 11, 2020, 20:55 jamesbeedy [e-mail] wrote:

From a charm author perspective, we just want to know if we are the leader or not. To me, the naming is_leader() implies that would be able to get a boolean return similar to the is-leader command. I’m wondering if it would be more consistent and direct to mirror the functionality/output of the is-leader command and allow charm authors to simply handle a boolean return instead of a possible exception. I feel this more closely mirrors the existing is_leader() functionality in charmhelpers, and would allow the charm author to more directly solve the problem of determining if the unit is the leader.

Am I way off base here, does this make sense to others too?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/canonical/operator/issues/269#issuecomment-626824067, or unsubscribe https://github.com/notifications/unsubscribe-auth/AABRQ7OIJWBVBANW6XCQXWLRRAUYBANCNFSM4M5QA2DQ .