Thanks for kicking this off Mike. I added a few "rejected alternatives" and put a few questions for thought in a comment. You may want to keep all discussion in this email thread, so here are the questions copied:
This is promising! Question: Would this mode be valuable also for Kubernetes deployments, i.e. we could get rid of the ZookeeperOperator and instead let the SolrOperator keep track of which Solr pods that also act as ZK nodes? Would we allow a Solr node to start in a ZK-only mode, i.e. not eligible for collections/cores/overseer? This would also support those huge clusters where you want dedicated ZKs. This also ties in with SIP-6 Solr should own the bootstrap process <https://cwiki.apache.org/confluence/display/SOLR/SIP-6+Solr+should+own+the+bootstrap+process>, as we'd want to control startup/shutdown behavior wrt the zk, e.g. start embedded zk before solr and stop solr before stopping zk. Perhaps also gracefully exiting the quorum on planned shutdown? Jan > 14. sep. 2021 kl. 22:09 skrev Mike Drob <md...@apache.org>: > > Devs, > > We've previously discussed maintaining ZK as being an operational hurdle for > some groups getting started or migrating to SolrCloud from non-ZK cloud mode. > I'd like to discuss the idea of embedding ZK in our own process control. > > Please see the SIP at > https://cwiki.apache.org/confluence/display/SOLR/SIP-14+Embedded+Zookeeper > <https://cwiki.apache.org/confluence/display/SOLR/SIP-14+Embedded+Zookeeper> > > Thank you, > Mike
