bq. Isn’t solr.xml is a way to hardcode config in a more flexible way that a Java class?
Yes, and the problem word here is “flexible”. For a single-node system that flexibility is desirable. Flexibility comes at the cost of complexity, especially in the SolrCloud case. In this case, not so much Solr code complexity as operations complexity. For me this isn’t so much a question of functionality as administration/troubleshooting/barrier to entry. If: 1. you can guarantee that every solr.xml file on every node in your entire 500 node cluster is up to date 2. or you can guarantee that the solr.xml stored on Zookeeper 3. and you can guarantee that clusterprops.json in cloud mode is interacting properly with whichever solr.xml is read 4. Then I’d have no problem with solr.xml. However, 1, 2, and 3, are not trivial for a large number of Solr nodes and if they aren’t right diagnosing them can be “challenging”… Imagine all the ways that “somehow” the solr.xml file on one node or more nodes of a 500 node cluster didn’t get updated and you’re trying to track down why query X isn’t working as you expect. Some of the time. When you happen to hit conditions X, Y and Z on a subrequest that goes to the node in question (which won’t be all of the time, or even possibly a significant fraction of the time). Do Containers matter here? Some glitch in Puppet or similar? Somebody didn’t follow every step in the process in the playbook? It doesn’t matter how you got into this situation, tracking it down would be a nightmare. Or, for that matter, you’ve solved all the distribution concerns and _can_ guarantee 1 and 3. Then somebody pushes a solr.xml to ZK either intentionally or by mistake (OH, I thought I was on the QA system, oops). Now I get to spend a week tracking down why the guarantee of 1 is still true, it’s just not relevant any more. To me, it’s the same problem that is solved by the blob store for jar files, or having configsets in ZK. When I want something available to all my Solr instances, I do not want to have to run around to every node and determine that the object I copied there is the right one, especially if I’m trying to track down a problem. Sure, all my concerns can be solved, but why make it harder than it needs to be? Distributed systems are hard enough already… FWIW, Erick > On Sep 3, 2020, at 11:00 AM, Ilan Ginzburg <[email protected]> wrote: > > Isn’t solr.xml is a way to hardcode config in a more flexible way that a > Java class? --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
