[
https://issues.apache.org/jira/browse/SOLR-15959?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17484607#comment-17484607
]
Jan Høydahl commented on SOLR-15959:
------------------------------------
Name change could help people visualize what should go in there, but I guess we
can live with solr.xml too.
[~hossman] you have done some work around this loading of solr.xml from zk. How
do you feel about the matter now? Is it broadly used, and is it still a good
idea to load this (node-centric) file from zk?
> Deprecate loading of solr.xml from ZK
> -------------------------------------
>
> Key: SOLR-15959
> URL: https://issues.apache.org/jira/browse/SOLR-15959
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Reporter: Jan Høydahl
> Priority: Major
>
> In SOLR-9268, five years ago (committed by me) we allowed loading of solr.xml
> from zookeeper.
> Part of the motivation back then was to be able to put {{solr.xml}} in a
> central place and not being forced to initialize {{SOLR_HOME}} with that
> file, similar to the goal of SOLR-9575. And perhaps also an easy way to
> update solr.xml.
> However, I think it may have been a mistake that should be deprecated and
> ultimately removed. Why? The {{solr.xml}} file is the "node config" for solr.
> Where you set node-level props that need to be there at early node startup.
> So even if you change the file in ZK, nodes will have not way of reloading
> those plugins dynamically without a restart
> The file may even contain local-node-specific settings that shuold differ
> from node to node. Especially during rolling upgrade, it may be important to
> be able to have a different {{solr.xml}} on the new nodes and on the old
> ones. With property substitution you can do some of that, but you cannot add
> XML tags with a sysprop.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
