In the latest Virtual Community Meetup, Pierre and Bruno shared that they recently enabled "no-overseer" mode (really need a better name!) at their workplace in production and were hitting some stability issues. Their anecdotes give me at least some "pause" about whether this is really ready to be the default, or whether it needs a bit more time to bake.
Any chance either of them are watching this thread and can provide an update or their own 2c here? Best, Jason On Wed, Aug 20, 2025 at 6:35 PM David Smiley <[email protected]> wrote: > > 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 <[email protected]> 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 > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
