[ https://issues.apache.org/jira/browse/SOLR-11005?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16073700#comment-16073700 ]
Shalin Shekhar Mangar edited comment on SOLR-11005 at 7/4/17 2:29 PM: ---------------------------------------------------------------------- -I also think that we should do this in 7.0 because the policy framework is already being released as part of it. Therefore I propose that this be made a blocker for 7.0 release.- Actually on further thought, although this behavior is not desirable, there is no technical reason why this should block 7.0. Lets defer this for 7.1 was (Author: shalinmangar): I also think that we should do this in 7.0 because the policy framework is already being released as part of it. Therefore I propose that this be made a blocker for 7.0 release. > 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) > Reporter: Noble Paul > > 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 (v6.4.14#64029) --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org