[
https://issues.apache.org/jira/browse/SOLR-4718?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13633350#comment-13633350
]
Erick Erickson commented on SOLR-4718:
--------------------------------------
[~elyograg]
Note the structure here. Solr.xml has something like
<solr>
<solrcloud>
<int name="hostPort">${hostPort:44}</int>
</solrcloud>
</solr>
but solr.properties just has
hostPort=55
so solr.properties _always_ overrides solr.xml. If you don't put the ${} syntax
in, you don't get the substitution.....
[~wunder]
about syntax errors. How about blow up, first time, every time. As in refuse to
start Solr? This will still be at startup. Fail early, fail often.....
[[email protected]]
bq: zkSolrXmlPath ... -1 on this guy.
This has nothing to do with local support and everything to do with where on ZK
the solr.xml file is. I don't have strong feelings either way, but if we want
to support multiple wars in the same JVM that have different solr.xmls seems
like we need a way to distinguish where they are stored on ZK. That said, on
the KISS principle I can get behind "OK, define a generic solr.xml, it always
lives in the root on ZK and put your changes in the solr.properties file that
exists locally". We can always add this later iff a good use-case comes up
requiring it.
All:
I'm having something of a problem with solr.properties only being disk-based
(even though I'd also like it to be). How do we get it there in the first
place? Here's what I'm thinking; it should be possible to just install a stock
solr with _no_ modifications on a node, fire it up _without_ having any
a-priori files and be done with it. If we require the "correct" solr.properties
file to be there why don't we just require the correct solr.xml and not bother
with a properties file? (I'm over-stating the case here, but....)
I want to say "java -DzkHost=blah -jar start.jar" and be done with it. I'm
probably missing something, but any time we require local files (in this case
solr.properties), whether an installation uses any of the auto-config tools or
not, it seems like the same problem as requiring the "right" version of
solr.xml.
Or is this just one of those cases where I'm over-thinking it and I should just
get over it and assume anyone who wants all this flexibility is also capable of
getting the right solr.properties file in the right place?
> 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: [email protected]
For additional commands, e-mail: [email protected]
