[
https://issues.apache.org/jira/browse/SOLR-9743?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15651133#comment-15651133
]
Erick Erickson commented on SOLR-9743:
--------------------------------------
Interesting. We've always been "collection centric", where the hardware is left
"as an exercise for the reader". This seems more operations wide, "I just got
some new hardware, here Solr, make use of it". Cool!
I'm not sure I see the use-case for the version without the collection name,
doubtless you have something in mind here. My immediate reaction though is that
if the version that adds replicas to all collections is at all difficult I
could live without it and have collection be required (and perhaps
multiValued?). Although I supposed if you allow a multivalued collection
parameter the leap from there to doing it for every collection is trivial
code-wise, it'd just be whether you read the list from the param or got a list
of collections from ZK...
> An ADDNODE command
> ------------------
>
> Key: SOLR-9743
> URL: https://issues.apache.org/jira/browse/SOLR-9743
> Project: Solr
> Issue Type: Sub-task
> Security Level: Public(Default Security Level. Issues are Public)
> Reporter: Noble Paul
>
> The command would accept one or more nodes and create appropriate replicas
> based on some strategy.
> The params are
> *node: (required && multi-valued) : The nodes to be added
> * collection: (optional) The collection to which the node should be added
> to. if this parameter is not passed, try to assign to all collections
> * strategy: (required) A strategy implementation
> * strategy.<param>: (optional) Parameters to be passed to the strategy
> example:
> {code}
> action=ADDNODE&collection=gettingstarted&strategy=optimalCoreCount&strategy.maxCores=8
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
