The logs show that leader-elected isn't implemented, which probably means that you can suffer from comment #13:
2017-10-27 16:35:31 INFO juju-log Unknown hook leader-elected - skipping.
I was discussing with Andrew, and one thing that we are thinking about this cycle is trying to introduce Application <=> Application relation data, rather than just having Unit <=> Application data.
In that context, it would be interesting to consider having a "relation-joined/changed" hook that is actually *guaranteed* to fire on the current leader, and if leadership changes and the hook has not exited successfully in the past, then the hook is triggered on the new leader.
The initial scope around Application data bags would not change the hook logic, so it wouldn't actually address this bug, but in the stuff we are calling "charms v2" and trying to change what hooks are fired, we could potentially address it there.
Potentially we could introduce a new hook more easily than deprecating all the existing hooks that we fire. Which would allow you to have something like "application-relation-changed", or some other spelling. Having some sort of knowledge around "what is the latest version of relation data that a leader has processed for all of its relations" and then always triggering a 'changed' hook whenever either the leader changes or the relation changes, and then recording that a leader has processed up to 'revno=X'.
The logs show that leader-elected isn't implemented, which probably means that you can suffer from comment #13:
2017-10-27 16:35:31 INFO juju-log Unknown hook leader-elected - skipping.
I was discussing with Andrew, and one thing that we are thinking about this cycle is trying to introduce Application <=> Application relation data, rather than just having Unit <=> Application data. joined/ changed" hook that is actually *guaranteed* to fire on the current leader, and if leadership changes and the hook has not exited successfully in the past, then the hook is triggered on the new leader.
In that context, it would be interesting to consider having a "relation-
The initial scope around Application data bags would not change the hook logic, so it wouldn't actually address this bug, but in the stuff we are calling "charms v2" and trying to change what hooks are fired, we could potentially address it there.
Potentially we could introduce a new hook more easily than deprecating all the existing hooks that we fire. Which would allow you to have something like "application- relation- changed" , or some other spelling. Having some sort of knowledge around "what is the latest version of relation data that a leader has processed for all of its relations" and then always triggering a 'changed' hook whenever either the leader changes or the relation changes, and then recording that a leader has processed up to 'revno=X'.