I have typically provisioned zookeeper first, and prepped it before running spinning up a solr pointing to it. That's also what typically happens with the solr Operator, it starts Zookeeper ensemble first, then an init container will bootstrap e.g. security.json to zookeeper before starting the Solr PODs.
But I'd love for ZK to be percieved as an internal component hidden behind Solr APIs. If we decide on that as a goal, we'll need to find the remaining gaps in API coverage. There are also some chicken/egg situations, such as enabling SSL through props in zk, but David is fixing at least that one. We should probably have another look at all other ZK-hosted files if there exist a Solr API to manage it. Jan > 12. mai 2026 kl. 14:14 skrev David Eric Pugh via dev <[email protected]>: > > Does anyone stand up ZooKeeper first, and then use the Solr CLI to interact > with it, for example, by uploading configsets or maybe setting some Cluster > Properties, before any Solr nodes are started? > I ask because as we have matured the V2 API and added more SolrJ http apis, > there has been some interest in making Solr CLI use HTTP instead of talking > direct to ZooKeeper. > There is also some interesting work in > https://github.com/apache/solr/pull/4320 that moves us in that direction as > well. > I struggle in my direct experience to think about where I have configured > ZooKeeper independent of Solr, and indeed it feels like an anti-pattern since > the Solr APIs are where we have lots of validation etc. And having > ZooKeeper exposed directly to the CLI seems also to have it's own issues from > a security perspective. > So was curious if this is a real need? > Eric --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
