[
https://issues.apache.org/jira/browse/SOLR-4478?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13603565#comment-13603565
]
Erick Erickson commented on SOLR-4478:
--------------------------------------
Starting on this finally, couple of points for discussion:
What do we do with each of these if we find a configSet entry in the
core.properties file?
> instanceDir - nothing to do here except we don't look here for configuration
> files
> dataDir - again, nothing. The meaning remains unchanged.
> config - check that it exists in the config set and blow up if we don't
> find it.
> schema - treat as config.
for config and schema, it hurts my head to think of resolving relative paths,
absolute paths, the relationship to solr_home, the relationship of referenced
files ( stopwords, etc). At least for the first cut I want to allow the config
and schema files to be a different name, but that's it. And require that they
live in the configSet directory. Unless all of this just automagically happens
through the resource loader.
The properties entry in the core.properties file (doesn't depend on configSet)
- does it make sense to have it any more at all? I propose we deprecate it.
Is there a convenient place in the SolrCloud code that I can rip off? I'll look
but I don't want to re-invent the wheel if I miss it....
> Allow cores to specify a named config set
> -----------------------------------------
>
> 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
> Assignee: Erick Erickson
>
> 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 is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
