[
https://issues.apache.org/jira/browse/SOLR-4718?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13633123#comment-13633123
]
Erick Erickson commented on SOLR-4718:
--------------------------------------
My head's exploding. We have two files, solr.xml and solr.properties, plus the
absence of either. Stored either locally or on ZK. What's the precedence here?
I vote that solr.properties be only local.
So, some straw-man rules....
> solr.properties is irrelevant without a solr.xml, it's used only to sub in
> ${} type constructs.
> solr.properties can exists only locally. Don't look on ZK under any
> conditions.
> solr.properties definitions take precedence over _any_ definitions in
> solr.xml either local or from ZK.
Note: my objection to making it possible to store solr.properties in ZK is that
it complexifies things and one can centrally store a complete solr.xml file
there just as easily. I can be persuaded otherwise, but I want a real use case
not a theoretical one. We can always add that on later too. Except how does
this play when creating collections? I guess that's irrelevant, the solr home
is what counts.
> if solr.xml is local, we look for one on ZK iff zkSolrXmlPath is defined (in
> solr.xml or as a sysprop). Overlay the local one if so. Then apply
> solr.properties to the combined solr.xml
> if no solr.xml is found locally but zkRun or zkHost is defined (sys props),
> then look in ZK(root or sysprop zkSolrXmlPath) for solr.xml and use that.
> Overlay with local solr.properties if present.
# So the multiple war in single JVM case is handled; you don't have to have any
sysprops if you have a solr.xml/solr.properties pair defined in solrhome for
each war. And you can still define a minimal file that just points to ZK for
the "real" solr.xml file.
# The no-local-config case is handled by deciding to NOT have a solr.xml
locally, set the necessary sysprops (zkhost and possibly zkSolrXmlPath. With or
without a solr.properties file.
# The mixed case is handled by having remote solr.xml but local solr.properties
in each solrhome to override values.
> Allow solr.xml to be stored in zookeeper
> ----------------------------------------
>
> Key: SOLR-4718
> URL: https://issues.apache.org/jira/browse/SOLR-4718
> Project: Solr
> Issue Type: Improvement
> Components: Schema and Analysis
> Affects Versions: 4.3, 5.0
> Reporter: Erick Erickson
> Assignee: Erick Erickson
>
> So the near-final piece of this puzzle is to make solr.xml be storable in
> Zookeeper. Code-wise in terms of Solr, this doesn't look very difficult, I'm
> working on it now.
> More interesting is how to get the configuration into ZK in the first place,
> enhancements to ZkCli? Or boostrap-conf? Other? I'm punting on that for this
> patch.
> Second level is how to tell Solr to get the file from ZK. Some possibilities:
> 1> A system prop, -DzkSolrXmlPath=blah where blah is the path _on zk_ where
> the file is. Would require -DzkHost or -DzkRun as well.
> > pros - simple, I can wrap my head around it.
> - easy to script
> > cons - can't run multiple JVMs pointing to different files. Is this
> really a problem?
> 2> New solr.xml element. Something like:
> <solr>
> <solrcloud>
> <str name="zkHost">zkurl</str>
> <str name="zkSolrXmlPath">whatever</str>
> </solrcloud>
> <solr>
> Really, this form would hinge on the presence or absence of zkSolrXmlPath.
> If present, go up and look for the indicated solr.xml file on ZK. Any
> properties in the ZK version would overwrite anything in the local copy.
> NOTE: I'm really not very interested in supporting this as an option for
> old-style solr.xml unless it's _really_ easy. For instance, what if the local
> solr.xml is new-style and the one in ZK is old-style? Or vice-versa? Since
> old-style is going away, this doesn't seem like it's worth the effort.
> pros - No new mechanisms
> cons - once again requires that there be a solr.xml file on each client.
> Admittedly for installations that didn't care much about multiple JVMs, it
> could be a stock file that didn't change...
> For now, I'm going to just manually push solr.xml to ZK, then read it based
> on a sysprop. That'll get the structure in place while we debate. Not going
> to check this in until there's some consensus though.
--
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
