[ 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