[
https://issues.apache.org/jira/browse/SOLR-3488?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13398232#comment-13398232
]
Tommaso Teofili commented on SOLR-3488:
---------------------------------------
bq. Lets say you have 4 nodes with 2 collections on them. You want each
collection to use as many nodes as are available. Now you want to add a new
node. To get it to participate in the existing collections, you have to
configure them, or create new compatible cores over http on the new node.
Wouldn't it be nice if the Overseer just saw the new node, that the collections
had repFactor=MAX_INT and created the cores for you?
sure, that'd be nice indeed. Maybe this should be configurable (a param like
greedy=boolean)
bq. If you remove a collection, what happens when a node that was down comes
back and had that a piece of that collection? Your collection will be back as a
single node. An Overseer process could prune this off shortly after.
so basically, if I understood correctly, is that the overseer has the
capability of doing periodic checks without an explicit action / request from a
client which can help on cleaning states / check for failures / etc.
bq. So I think maybe we would need a new zk node where solr instances register
rather than cores? then we know what is available to place replicas on - even
if that Solr instance has no cores?
wouldn't be possible to store the instances information in the same zk node?
Because otherwise we could've to also check the two nodes are in consistent
states (I don't know Zookeeper very much so I may be wrong here)
> Create a Collections API for SolrCloud
> --------------------------------------
>
> Key: SOLR-3488
> URL: https://issues.apache.org/jira/browse/SOLR-3488
> Project: Solr
> Issue Type: New Feature
> Components: SolrCloud
> Reporter: Mark Miller
> Assignee: Mark Miller
> Attachments: SOLR-3488.patch, SOLR-3488.patch, SOLR-3488.patch,
> SOLR-3488_2.patch
>
>
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
