[jira] [Updated] (SOLR-6517) CollectionsAPI call ELECTPREFERREDLEADERS

["Erick Erickson (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/SOLR-6517?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Erick Erickson updated SOLR-6517:
---------------------------------
    Summary: CollectionsAPI call ELECTPREFERREDLEADERS  (was: CollectionsAPI call REELECTLEADERS)

> CollectionsAPI call ELECTPREFERREDLEADERS
> -----------------------------------------
>
>                 Key: SOLR-6517
>                 URL: https://issues.apache.org/jira/browse/SOLR-6517
>             Project: Solr
>          Issue Type: New Feature
>    Affects Versions: 5.0, Trunk
>            Reporter: Erick Erickson
>            Assignee: Erick Erickson
>
> Perhaps the final piece of SOLR-6491. Once the preferred leadership roles are assigned, there has to be a command "make it so Mr. Solr". This is something of a placeholder to collect ideas. One wouldn't want to flood the system with hundreds of re-assignments at once. Should this be synchronous or asnych? Should it make the best attempt but not worry about perfection? Should it???
> a collection=name parameter would be required and it would re-elect all the leaders that were on the 'wrong' node
> I'm thinking an optionally allowing one to specify a shard in the case where you wanted to make a very specific change. Note that there's no need to specify a particular replica, since there should be only a single preferredLeader per slice.
> This command would do nothing to any slice that did not have a replica with a preferredLeader role. Likewise it would do nothing if the slice in question already had the leader role assigned to the node with the preferredLeader role.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org