[
https://issues.apache.org/jira/browse/SOLR-15232?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17316287#comment-17316287
]
Jan Høydahl commented on SOLR-15232:
------------------------------------
I'm confused by where this suggestion fits in. Sounds too low-level and
mal-placed at first sight...
In a containerized environment you have three levels at which scaling decisions
can happen, roughly 1) inside the Solr cluster itself (auto-scaling) 2) the
container orchestrator in charge of starting new pods (e.g. k8s) and 3) an
external agent that can give outside orders to either Solr or k8s (e.g.
solr-operator).
So instead of hard-coding in a script at node startup what exact replica to
add, is it not better to design a tighter integration between solr
autoscaling/metrics and solr-operator in such a way that solr-operator can
start pods and utilize them as needed by the solr cluster?
> Add replica(s) as a part of node startup
> ----------------------------------------
>
> Key: SOLR-15232
> URL: https://issues.apache.org/jira/browse/SOLR-15232
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Reporter: Andrzej Bialecki
> Assignee: Andrzej Bialecki
> Priority: Major
> Fix For: main (9.0)
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> In containerized environments it would make sense to be able to initialize a
> new node (pod) and designate it immediately to hold newly created replica(s)
> of specified collection/shard(s) once it's up and running.
> Currently this is not easy to do, it requires the intervention of an external
> agent that additionally has to first check if the node is up, all of which
> makes the process needlessly complicated.
> This functionality could be as simple as adding a command-line switch to
> {{bin/solr start}}, which would cause it to invoke appropriate ADDREPLICA
> commands once it verifies the node is up.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
