lucene-dev mailing list archives

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

    [ 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.....


[~markrmiller@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-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org


Mime
View raw message