You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sling.apache.org by "Alexander Saar (JIRA)" <ji...@apache.org> on 2018/08/15 12:06:00 UTC

[jira] [Commented] (SLING-7830) Defined leader switch

    [ https://issues.apache.org/jira/browse/SLING-7830?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16580985#comment-16580985 ] 

Alexander Saar commented on SLING-7830:
---------------------------------------

I see 2 scenarios:
 * control the leader in same topology: either via an API to make an implicit switch to another leader after deployment or force leader duringĀ first startup when a new process with a newer version is deployed (subsequent startups/deploys would always have newer version, so think this should be ok)
 * 2 separate topologies (with 2 independent masters): much harder to control and not sure if really required. maybe focus should be on first option initially.

> Defined leader switch
> ---------------------
>
>                 Key: SLING-7830
>                 URL: https://issues.apache.org/jira/browse/SLING-7830
>             Project: Sling
>          Issue Type: Improvement
>          Components: Discovery
>            Reporter: Carsten Ziegeler
>            Priority: Major
>
> The current leader selection is based on startup time and sling id (mainly) and is stable across changed in the topology for as long as the leader is up and running.
> However there are use cases like blue green deployment where new instances with a new version are started and taking over the functionality. However with the current discovery setup, the leader would still be one of the instances with the old version.
> With a new deployed version, tasks currently bound to the leader should run on the new version.
> Therefore the leader needs to switch and stay the leader (until it dies).
> We probably need an additional criteria for the leader selection
> /cc [~egli]



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)