[jira] [Commented] (SOLR-4478) Allow cores to specify a named config set in non-SolrCloud mode

["Trey Grainger (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/SOLR-4478?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13787277#comment-13787277 ] 

Trey Grainger commented on SOLR-4478:
-------------------------------------

(moving this from my previous e-mail to the solr-dev mailing list)

There are two use-cases that appear broken with the new core auto-discovery mechanism:

1) *The Core Admin Handler's CREATE command no longer works to create brand new cores* 
(unless you have logged on the box and created the core's directory structure manually, which largely defeats the purpose of the "CREATE" command).  With the old Solr.xml format, we could spin up as many cores as we wanted to dynamically with the following command:
http://localhost:8983/solr/admin/cores?action=CREATE&name=newCore1&instanceDir=collection1&dataDir=newCore1/data
...
http://localhost:8983/solr/admin/cores?action=CREATE&name=newCoreN&instanceDir=collection1&dataDir=newCoreN/data

In the new core discovery mode, this exception is now thrown:
Error CREATEing SolrCore 'newCore1': Could not create a new core in solr/collection1/as another core is already defined there

The exception is being intentionally thrown in CorePropertiesLocator.java because a core.properties file already exists in solr/collection1 (and only one can exist per directory).


2) *Having a shared configuration directory (instanceDir) across many cores no longer works.*  
Every core has to have it's own conf/ directory, and this doesn't seem to be overridable any longer.  Previously, it was possible to have many cores share the same instanceDir (and just override their dataDir for obvious reasons).  Now, it is necessary to copy and paste identical config files for each Solr core.


I don't know if there's already a current roadmap for fixing this.  I saw https://issues.apache.org/jira/browse/SOLR-4478, which suggested replacing instanceDir with the ability to specify a named configSet.  This solves problem 2, but not problem1 (since you still can't have multiple core.properties files in the same folder).  Based on Erick's comments in the JIRA ticket, it also sounds like this ticket is also dead at the moment.

There is definitely a need to have a shared config directory - whether that is through a configSet or an explicit indexDir doesn't matter to me.  There's also a need to be able to dynamically create Solr cores from external systems.  I currently can't upgrade to core auto discovery because it doesn't allow dynamic core creation.  Does anyone have some thoughts on how to best get these features working again under core autodiscovery?  Adding instanceDir to core.properties seems like an easy solution, but there must be a desire not to do that or it would probably have already been done.

I'm happy to contribute some time to resolving this if there is agreed upon path forward.

> 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