Update: I proposed the Solr version go into cluster properties[1] on ZK initialization but Houston pushed back on that approach. The other approach is to rely on the "least Solr version" as returned by the Solr version being added to live nodes[2]. However that's very dynamic and I'm concerned about an old Solr version somehow joining an existing cluster. Rather than simply tell users "don't do that" (which we should do anyway), I'm inclined to have Solr fail to join an existing cluster if doing so would *lower* the least Solr version. Perhaps ignoring the final patch version. I plan on updating that PR accordingly. The PR would have to go into 9.x too, and thus such logic can't be enforced for older Solr versions. Regardless, an upgrading user can choose the setting.
[1] https://issues.apache.org/jira/browse/SOLR-17664 [2] https://issues.apache.org/jira/browse/SOLR-17620 On Tue, Jul 22, 2025 at 1:12 AM David Smiley <dsmi...@apache.org> wrote: > On the epic of seeking the _eventual_ demise of the Overseer, I'm seeking > to make it disabled for *new* SolrCloud clusters in Solr 10. -- > https://issues.apache.org/jira/browse/SOLR-17293 > The epic: https://issues.apache.org/jira/browse/SOLR-14927 (oddly no SIP > but it has a doc anyway). I think it's sufficiently ready for the great > majority of SolrCloud clusters. A cluster with a collection containing a > thousand+ replicas might pose a performance concern on start/restart events > due to independent replica state updates. Of course, with such a change, > there will be a section in the upgrade page in the ref guide to advise > users who may opt to make an explicit choice. > > I don't love that the new mode doesn't have an elegant/clear way to refer > to it. The best I've come up with is to say what it *isn't* -- it *isn't* > the Overseer. "The Overseer is disabled". Awkwardly there are two > undocumented solr.xml booleans, both a mouthful: > distributedClusterStateUpdates and > distributedCollectionConfigSetExecution. I propose instead that a single > boolean cluster property be defined named "overseer" or "overseerEnabled". > FYI the existing known cluster properties are defined here: > org.apache.solr.common.cloud.ZkStateReader#KNOWN_CLUSTER_PROPS > Even if such a boolean is agreeable... it raises the question of what > should become of the "overseer" node role. > > ~ David Smiley > Apache Lucene/Solr Search Developer > http://www.linkedin.com/in/davidwsmiley >
