[ https://issues.apache.org/jira/browse/SOLR-4718?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13633201#comment-13633201 ]
Mark Miller commented on SOLR-4718: ----------------------------------- bq. I can't quite decide which should be the 'winner' for a config item that's in both solr.properties and solr.xml There will be no decision necessary on this - the two will not compete. This is all very simple stuff that already works and has been around in Solr for a long time. > 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