David Smiley commented on SOLR-9735:

It appears that the precommit detection of "nocommit" string does not look in 
.json documents.  I see it in 
solr/solrj/src/resources/apispec/autoscaling.Commands.json for documentation 
that is nonexistent.   build.xml line 137 (ant target 
"-validate-source-patterns") references file extensions but not .json.  Can you 
fix this and the actual nocommit [~shalinmangar]?

> Umbrella JIRA for Auto Scaling and Cluster Management in SolrCloud
> ------------------------------------------------------------------
>                 Key: SOLR-9735
>                 URL: https://issues.apache.org/jira/browse/SOLR-9735
>             Project: Solr
>          Issue Type: New Feature
>      Security Level: Public(Default Security Level. Issues are Public) 
>            Reporter: Anshum Gupta
>            Assignee: Shalin Shekhar Mangar
>   Original Estimate: 1,344h
>  Remaining Estimate: 1,344h
> As SolrCloud is now used at fairly large scale, most users end up writing 
> their own cluster management tools. We should have a framework for cluster 
> management in Solr.
> In a discussion with [~noble.paul], we outlined the following steps w.r.t. 
> the approach to having this implemented:
> * *Basic API* calls for cluster management e.g. utilize added nodes, remove a 
> node etc. These calls would need explicit invocation by the users to begin 
> with. It would also specify the {{strategy}} to use. For instance I can have 
> a strategy called {{optimizeCoreCount}} which would target to have an even 
> no:of cores in each node . The strategy could optionally take parameters as 
> well
> * *Metrics* and stats tracking e.g. qps, etc. These would be required for any 
> advanced cluster management tasks e.g. *maintain a qps of 'x'* by 
> *auto-adding a replica* (using a recipe) etc. We would need 
> collection/shard/node level views of metrics for this.
> * *Recipes*: combination of multiple sequential/parallel API calls based on 
> rules. This would be complicated specially as most of these would be long 
> running series of tasks which would either have to be rolled back or resumed 
> in case of a failure.
> * *Event based triggers* that would not require explicit cluster management 
> calls for end users.

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