[
https://issues.apache.org/jira/browse/SLING-7830?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16585998#comment-16585998
]
Stefan Egli commented on SLING-7830:
------------------------------------
Had an offline discussion with [~mreutegg] about
bq. With a new deployed version, tasks currently bound to the leader should run
on the new version.
What's the reasoning for forcing jobs to run in the new cluster right away? Is
that really necessary? In theory the jobs could also stay on the old leader and
at some point the old cluster part is taken offline and any jobs that weren't
finished or where queued would automatically get assigned to the new
cluster/leader.
> 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
> Assignee: Stefan Egli
> Priority: Major
> Time Spent: 10m
> Remaining Estimate: 0h
>
> 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)
