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