[
https://issues.apache.org/jira/browse/SOLR-9735?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16028583#comment-16028583
]
Shalin Shekhar Mangar commented on SOLR-9735:
---------------------------------------------
It has been a couple of months since we shared the initial design document. So
a quick update is in order. The policy and preference engine is mostly done so
that is going to be the first thing that we will merge to master. The trigger
support and rest of the autoscaling features are still being worked on and it
is likely that they won't have enough testing before Solr 7. So our plan is to
create a new branch off of master with just the bits from autoscaling branch
that we feel are ready for merge/release in Solr 7. These include:
# The policy and preference engine
# The associated set-policy, set-cluster-policy and set-cluster-preferences API
# The autoscaling read and diagnostics API
# MOVEREPLICA API (which is already present in master)
# SOLR-10419 -- which changes all collection APIs to use the policy engine to
place replicas
I'll shortly be creating a feature/autoscaling_solr7 branch for these bits and
we hope to merge it to master this week. I'll add a comment here once the
branch is ready for review.
> 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.3.15#6346)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
