[ https://issues.apache.org/jira/browse/SOLR-9735?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16170464#comment-16170464 ]
Shalin Shekhar Mangar commented on SOLR-9735: --------------------------------------------- There are a good chunk of features that have accumulated in the feature/autoscaling branch. I am going to review the remaining nocommits and tests so that we can merge this branch to master. I'll hold off merging to branch_7x until we can finish SOLR-11085. We have another branch named feature/autoscaling_72 which contains features that we plan to release in 7.2. Once autoscaling branch is merged to master, we can get rid of autoscaling_72 and continue further development on the autoscaling branch itself. > 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 (v6.4.14#64029) --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org