[
https://issues.apache.org/jira/browse/SOLR-5609?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13910587#comment-13910587
]
Noble Paul commented on SOLR-5609:
----------------------------------
bq. This doesn't seem right? Why was this added? We can't have special code
that looks for http anymore.
I didn't add this either , I guess the last SVN merge screwed up a lot of stuff
. I'm looking into the code and removing the wrong additions
bq.I thought the cluster props were managed via the collections api?
The CollectionsHandler is just posting this request to Overseer Queue directly.
Unlike most of our APIs this one just does not need the help of OCP.
> Don't let cores create slices/named replicas
> --------------------------------------------
>
> Key: SOLR-5609
> URL: https://issues.apache.org/jira/browse/SOLR-5609
> Project: Solr
> Issue Type: Sub-task
> Components: SolrCloud
> Reporter: Noble Paul
> Fix For: 4.7, 5.0
>
> Attachments: SOLR-5609_5130.patch, SOLR-5609_5130.patch,
> SOLR-5609_5130.patch, SOLR-5609_5130.patch
>
>
> In SolrCloud, it is possible for a core to come up in any node , and register
> itself with an arbitrary slice/coreNodeName. This is a legacy requirement and
> we would like to make it only possible for Overseer to initiate creation of
> slice/replicas
> We plan to introduce cluster level properties at the top level
> /cluster-props.json
> {code:javascript}
> {
> "noSliceOrReplicaByCores":true"
> }
> {code}
> If this property is set to true, cores won't be able to send STATE commands
> with unknown slice/coreNodeName . Those commands will fail at Overseer. This
> is useful for SOLR-5310 / SOLR-5311 where a core/replica is deleted by a
> command and it comes up later and tries to create a replica/slice
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
