Re: comment #21 and gating; if this is fully async, then gating is only
going to tighten the race, but not eliminate it. i.e. code like:
if is_leader():
leader_set(...)
can still error as the leadership could be lost between the two calls.
The only safe way of doing leadership code is probably something like:
if is_leader():
try:
# do things you have to do before calling leader_set()
leader_set(...) # if this passes, we are the leader
# do other things that depend on being the leader
except NotImplementedError: # because that's what bizarrely is
returned by charmhelpers
# we're not the leader after all (or something else ... can't
really tell)
if not is_leader():
# we're not the leader any more, undo any damage
else:
raise # something else went wrong
except OtherErrorsTheCodeMayHaveThrownIfWeAreInterested:
# etc
Anyone spot any problems? If this is a pattern, we should try to get it
into charmhelpers as a context manager or similar.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1654116
Title:
Attempts to write leadership settings when not the leader during
relation-changed hooks
To manage notifications about this bug go to:
https://bugs.launchpad.net/autopilot-log-analyser/+bug/1654116/+subscriptions
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
