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
