[ https://issues.apache.org/jira/browse/SOLR-4718?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13633177#comment-13633177 ]
Shawn Heisey commented on SOLR-4718: ------------------------------------ Guiding principle that I think needs to be observed: Any increase in complexity must come with a tangible benefit to a substantial percentage of the user base. I agree that solr.properties should only be disk-based. I can't quite decide which should be the 'winner' for a config item that's in both solr.properties and solr.xml, but I am leaning towards the .properties entry. In a world that includes both solr.properties and solr.xml, perhaps solr.xml becomes a truly global config file, affecting the whole cluster and living in zookeeper, with server-specific overrides living in solr.properties. If solr.xml lives in zookeeper, then how do we initially upload it or update it? Would a Solr restart be required for changes to take effect? Will it be possible to get SolrCloud started if the only thing you have is zkHost in solr.properties? Side issue: it would be really cool to be able to upload and partially update config sets (and possibly solr.xml) from within the admin UI, and/or with an API like /admin/cores. The current zookeeper bootstrap/cli is made for uploading named configs, but solr.xml is different, more global. I'm reluctant to keep expanding the commandline options for bootstrapping or zkcli, but perhaps a cluster-wide solr.xml is a good reason for it. > 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