[
https://issues.apache.org/jira/browse/SOLR-15959?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17689627#comment-17689627
]
Jan Høydahl commented on SOLR-15959:
------------------------------------
Circling back to this topic. On the user list thread
https://lists.apache.org/thread/cv0hbxrj6dpgvg98jhfwlb9dqjtr8htd there was no
real push-back or arguments for why to keep it in ZK, particularly now that you
can start a Solr node with an empty SOLR_HOME and it will pull the default
solr.xml from the release. Thus I'll proceed with deprecation in 9.2 and
removal in 10.0.
> Deprecate loading of solr.xml from ZK
> -------------------------------------
>
> Key: SOLR-15959
> URL: https://issues.apache.org/jira/browse/SOLR-15959
> Project: Solr
> Issue Type: Improvement
> Reporter: Jan Høydahl
> Priority: Major
>
> In SOLR-7735, 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.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org
For additional commands, e-mail: issues-h...@solr.apache.org
