[
https://issues.apache.org/jira/browse/SOLR-11005?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16073698#comment-16073698
]
Shalin Shekhar Mangar commented on SOLR-11005:
----------------------------------------------
Thanks Noble. The problem isn't about persisting this value. It is actually
about how to use it such that we avoid confusion.
We support {{replica}} in the cluster and collection policy using which a user
can limit the number of replicas on each node. The same thing is also supported
today with maxShardsPerNode parameter. However the two can easily conflict and
when they do, the current implementation tries to satisfy both (and the minimum
of them wins). This is very confusing. For example, if the cluster policy has:
{code}
{'replica':'<2', 'shard': '#EACH', 'node': '#ANY'}
{code}
and a user invokes the following on a cluster of 2 nodes:
{code}
/admin/collections?action=create&numShards=1&replicationFactor=6&maxShardsPerNode=10
{code}
Then the command fails saying that the cluster policy rule could not be
satisfied. This is in spite of the fact that the user had explicitly provided
{{maxShardsPerNode}} parameter.
I like this proposal. It removes confusion and preserves compatibility.
> 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: [email protected]
For additional commands, e-mail: [email protected]
