[
https://issues.apache.org/jira/browse/SOLR-15232?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17316994#comment-17316994
]
Jan Høydahl commented on SOLR-15232:
------------------------------------
Another option could be to start your container with a startup-script (see
[https://github.com/docker-solr/docker-solr#extending-the-image).] The script
can wait for solr (wait-for-solr.sh), then check that the collection exists (to
avoid chicken/egg), and finally add the replica to itself by reading ENV vars.
> 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: 20m
> 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
