You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@solr.apache.org by "David Smiley (Jira)" <ji...@apache.org> on 2022/09/20 22:40:00 UTC
[jira] [Commented] (SOLR-15959) Deprecate loading of solr.xml from ZK
[ https://issues.apache.org/jira/browse/SOLR-15959?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17607420#comment-17607420 ]
David Smiley commented on SOLR-15959:
-------------------------------------
I'm definitely a fan of using solr.xml as a node config for the reasons you listed. And for "immutable deployment" philosophy where this is in a Docker image you deploy. I'm not sure there's much gain in removing the functionality to load it form ZK though? I'm glad you asked on the users list; I personally haven't seen/heard someone using it in ZK. Perhaps the gain is philosophical / conceptual -- clarifying solr.xml's fundamental purpose? There's an argument to be had for *both* I think, if we could overlay solr.xml locally on top of one in ZK. Thus its location becomes, is it for the node or cluster.
> 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-unsubscribe@solr.apache.org
For additional commands, e-mail: issues-help@solr.apache.org