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