You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by "Trey Grainger (JIRA)" <ji...@apache.org> on 2013/10/05 19:48:43 UTC
[jira] [Comment Edited] (SOLR-4478) Allow cores to specify a named
config set in non-SolrCloud mode
[ https://issues.apache.org/jira/browse/SOLR-4478?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13787278#comment-13787278 ]
Trey Grainger edited comment on SOLR-4478 at 10/5/13 5:47 PM:
--------------------------------------------------------------
(Erick's response to my post)
Right, let's move this discussion to SOLR-4779. There's some history
here. Sharing named config sets got a bit wrapped up in sharing the
underlying solrconfig object. This latter has been taken off the
table, but we should discuss fixing Trey's issues up. Here's what the
thinking was:
There would be a directory like <solr_home>/configs/configset1,
<solr_home>/configs/configset2, etc. Then a new parameter for
core.properties or create or whatever like "configset=configset1" that
would be smart enough to look in <solr_home>/configs for an entire
conf directory named "configste1".
Trey:
Does that work for your case? If so, please add your comments to 4779
and we can take it from there. FWIW, I don't think this is especially
hard, but time is always at a premium.
was (Author: solrtrey):
(Eric's response to my post)
Right, let's move this discussion to SOLR-4779. There's some history
here. Sharing named config sets got a bit wrapped up in sharing the
underlying solrconfig object. This latter has been taken off the
table, but we should discuss fixing Trey's issues up. Here's what the
thinking was:
There would be a directory like <solr_home>/configs/configset1,
<solr_home>/configs/configset2, etc. Then a new parameter for
core.properties or create or whatever like "configset=configset1" that
would be smart enough to look in <solr_home>/configs for an entire
conf directory named "configste1".
Trey:
Does that work for your case? If so, please add your comments to 4779
and we can take it from there. FWIW, I don't think this is especially
hard, but time is always at a premium.
> Allow cores to specify a named config set in non-SolrCloud mode
> ---------------------------------------------------------------
>
> Key: SOLR-4478
> URL: https://issues.apache.org/jira/browse/SOLR-4478
> Project: Solr
> Issue Type: Improvement
> Affects Versions: 4.2, 5.0
> Reporter: Erick Erickson
> Attachments: SOLR-4478.patch, SOLR-4478.patch
>
>
> Part of moving forward to "the new way", after SOLR-4196 etc... I propose an additional parameter specified on the <core> node in solr.xml or as a parameter in the "discovery" mode core.properties file, call it configSet, where the value provided is a path to a directory, either absolute or relative. Really, this is as though you copied the conf directory somewhere to be used by more than one core.
> Straw-man: There will be a directory <solr_home>/configsets which will be the default. If the configSet parameter is, say, "myconf", then I'd expect a directory named "myconf" to exist in <solr_home>/configsets, which would look something like
> <solr_home>/configsets/myconf/schema.xml
> solrconfig.xml
> stopwords.txt
> velocity
> velocity/query.vm
> etc.
> If multiple cores used the same configSet, schema, solrconfig etc. would all be shared (i.e. shareSchema="true" would be assumed). I don't see a good use-case for _not_ sharing schemas, so I don't propose to allow this to be turned off. Hmmm, what if shareSchema is explicitly set to false in the solr.xml or properties file? I'd guess it should be honored but maybe log a warning?
> Mostly I'm putting this up for comments. I know that there are already thoughts about how this all should work floating around, so before I start any work on this I thought I'd at least get an idea of whether this is the way people are thinking about going.
> Configset can be either a relative or absolute path, if relative it's assumed to be relative to <solr_home>.
> Thoughts?
--
This message was sent by Atlassian JIRA
(v6.1#6144)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org