lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mark Miller (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (SOLR-4718) Allow solr.xml to be stored in zookeeper
Date Tue, 16 Apr 2013 23:53:17 GMT

    [ https://issues.apache.org/jira/browse/SOLR-4718?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13633575#comment-13633575
] 

Mark Miller commented on SOLR-4718:
-----------------------------------

bq. given the assumptions it's pretty straight-forward.

I'm pretty sure it is, just because it's so close to what is already done with solrcore.properties.

bq. a> solr.xml is a local file. Apply local solr.properties only if new-style (changes
when we stop supporting old-style solr.xml). Stop

Yeah, I think only new style is fine. Look how this is done with solrcore.properties - that's
a good starting point.

bq. b> zkhost is specified as a sysprop. Read solr.xml from ZK. If found, apply local solr.properties
(if any) and stop.

Right - as part of loading the solr.xml file you should be able to just pass along the props
you read like solrcore.properties.

bq. c> zkhost is specified in local solr.properties. Use it to get solr.xml from ZK. If
found, apply local solr.properties (if any) and stop

Right, the zkhost exception - we just first try and find it in this prop file if it exists
and zkhost is not found as a sys prop.

bq. d> Use the current hard-coded old-style solr.xml file. Do NOT apply any local solr.properties
(this will change when we stop supporting old-style solr.xml).

Yeah, that's back compat support and we don't need to add features for it IMO.
                
> 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-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org


Mime
View raw message