On 26 March 2015 at 23:58, Curtis Hovey-Canonical <[email protected]> wrote:
> ### Service Leader Elections > > Services running in an environment bootstrapped with the > "leader-election" feature flag now have access to three new hook tools: > > is-leader - returns true only if the executing unit is guaranteed > service leadership for the next 30s > leader-get - as relation-get; accessible only within the service > leader-set - as relation-set; will fail if not executed on leader > > ...and two new hooks: > > leader-elected - runs when the unit takes service leadership > leader-settings-changed - runs when another unit runs leader-set > > When a unit starts up, it will always run either leader-elected or > leader-settings-changed as soon as possible, delaying only doing so only > to run the install hook; complete any queued or in-flight operation; or > resolve a hook or upgrade error. Looking forward to this. Looking at the specifics, I'm interested in how the leader unit performs long running operations with the 30s lease. Lets say unit 0 is the leader, and decides that it is an appropriate time for unit 0 to run a repair operation that might take a few hours. As the wording currently stands, no hooks are triggered on the leader when the leader calls leader-set. This gives the leader no alternative but to perform the long running operation in the same hook, and risk another leader being elected and making a conflicting decision. I think that the leader-settings-changed hook needs to be called whenever *any* unit runs leader-set (including the current unit if it is the leader), rather than only when a different unit runs leader-set. This way, the leader can make its decisions and exit whatever hook triggered it within its 30s lease, and all units can perform their long running tasks in the leader-settings-changed hook. Alternatively, it could kick of an asynchronous task but they don't exist yet. Or would I need to run 'is-leader' in a thread every 30s to keep the lease renewed? -- Stuart Bishop <[email protected]> -- Juju-dev mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
