Noble Paul reassigned SOLR-11005:

    Assignee: Noble Paul

> inconsistency when maxShardsPerNode used along with policies
> ------------------------------------------------------------
>                 Key: SOLR-11005
>                 URL: https://issues.apache.org/jira/browse/SOLR-11005
>             Project: Solr
>          Issue Type: Improvement
>      Security Level: Public(Default Security Level. Issues are Public) 
>          Components: AutoScaling, SolrCloud
>            Reporter: Noble Paul
>            Assignee: Noble Paul
>             Fix For: 7.1
> The attribute maxShardsPerNode conflicts with the conditions in the new 
> Policy framework
> for example , I can say maxShardsPerNode=5 and I can have a policy 
> {code}
> { replica:"<3" , shard: "#ANY", node:"#ANY"}
> {code}
> So, it makes no sense to persist this attribute in collection state.json . 
> Ideally, we would like to keep this as a part of the policy and policy only.
> h3. proposed new behavior
> if the new policy framework is being used {maxShardsPerNode} should result in 
> creating a new collection specific policy with the correct condition. for 
> example, if a collection "x" is created with the parameter 
> {{maxShardsPerNode=2}} we will  create a new policy in autoscaling.json
> {code}
> {
> "policies":{
> "x_COLL_POLICY" : [{replica:"<3", shard:"#ANY" , node:"ANY"}]
> }
> }
> {code}
> this policy will be referred to in the state.json. There will be no attribute 
> called {{maxShardsPerNode}} persisted to the state.json.
> if there is already a policy being specified for the collection, solr should 
> throw an error asking the user to edit the policy directly
> h3.the name is bad
> We must rename the attribute {{maxShardsPerNode}} to {{maxReplicasPerNode}}. 
> This should be a backward compatible change. The old name will continue to 
> work and the API would give a friendly warning if the old name is used

This message was sent by Atlassian JIRA

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

Reply via email to