[jira] [Commented] (SOLR-4662) Finalize what we're going to do with solr.xml, auto-discovery, config sets.

["Erick Erickson (JIRA)" <ji...@apache.org>]

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

Erick Erickson commented on SOLR-4662:
--------------------------------------

I may actually have some time on some long flights to work on this, I'd really like to nail this and get it _over_. So I'd like to get the design agreed so I don't have to re-do the re-done.

It seems like the root issue here is that we have this configuration file that is trying to serve too many purposes. It started as a way to get basic configuration information back in the single-core days. Then it morphed into a place to get all the core information. Then it morphed into a place where we could specify a bunch of SolrCloud parameters. Then it morphed into a place to not really get core information but specify that that info get discovered. Now, with SolrCloud one question is whether we should even have it or should all this info be stored in Zookeeper. Having local files around that you have to have on each node before starting solr seems counter to having configurations managed by ZK.

Straw-man proposal:
 
So, what if we allow a "SolrConfigurationProvider"? Specifying none or the default we'll provide does just what happens now. It seems like the other stock one we could supply is one that reads the info from ZK. Don't know what else is out there, but that's just the point. People could plug in something that read their DB, something that read a properties file <G>. Whatever. There's a start on what the interface would look like here in ConfigSolr, which I pulled out when trying to make a properties file. I doubt it's entirely complete, but should be a pretty good start. Maybe this becomes an option on the command line? e.g. -Dsolr.configProvider="org.solr.core.XmlConfigProvider" as the default? And if -DzkHost="url to zk" is provided, default to -Dsolr.configProvider="org.solr.core.ZkConfigProvider"?

It seems like default behavior is then mostly a matter of which provider we use if none is specified. It'd be a pretty simple matter to switch between whether we use ZK or a solr.xml file based on whether we had a zkHost specified, and prefer the one that reads solr.xml in 4.x and the one that reads ZK in 5.x or whatever...

Let me be the first to say that I have NOT thought this through very carefully, and note how I'm glossing over getting the appropriate info up into ZK in the first place. My purpose here is to get the discussion going, I don't particularly care if this approach is adopted or not. I _do_ care that whatever we decide on doesn't do another 180 turn...

Let the discussion begin!


                
> Finalize what we're going to do with solr.xml, auto-discovery, config sets.
> ---------------------------------------------------------------------------
>
>                 Key: SOLR-4662
>                 URL: https://issues.apache.org/jira/browse/SOLR-4662
>             Project: Solr
>          Issue Type: Improvement
>    Affects Versions: 4.3, 5.0
>            Reporter: Erick Erickson
>            Assignee: Erick Erickson
>            Priority: Blocker
>
> Spinoff from SOLR-4615, breaking it out here so we can address the changes in pieces.

--
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: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org