Interestingly, the bin/solr cluster command was never documented in https://solr.apache.org/guide/solr/latest/deployment-guide/solr-control-script-reference.html, though it is in a rather hidden location in https://solr.apache.org/guide/solr/latest/deployment-guide/zookeeper-utilities.html#set-a-cluster-property documentation!
I also wonder if we could make uploading configsets as part of start up a lot smoother? Make it easy to upload N number of configsets so that upgrades could be performed. I did some testing of just startign ZK and seeing what worked and this is what I saw: docker run --name zookeeper --restart always -d -p 2181:2181 zookeeper # fails bin/solr zk mkroot mychroot # succeeds bin/solr zk mkroot --zk-host localhost:2181 mychroot # succeeds bin/solr zk ls --zk-host localhost:2181 / # succeeds bin/solr zk upconfig -z localhost:2181 -n mynewconfig -d ./server/solr/configsets/sample_techproducts_configs # succeeds bin/solr zk downconfig -z localhost:2181 -n mynewconfig -d /tmp # succeeds bin/solr cluster -z localhost:2181 --property urlScheme --value https On 2026/05/13 12:15:23 David Smiley wrote: > I said that the cluster prop was *not* related to SSL: "adding a cluster > property (albeit wasn't SSL; I forget what for)". For SSL in 10.1+, just > set solr.ssl.enabled=true or SOLR_SSL_ENABLED=true > > I think I now remember it was a replica placement plugin configuration: > https://solr.apache.org/guide/solr/latest/configuration-guide/cluster-plugins.html > I believe that such things should be possible to set in solr.xml but only > one of the plugin types can live there today, if I recall. > > Uploading the configset before Solr starts can be important in an upgrade > of plugins because the cores on the node should be loaded using the > configsets & plugins getting uploaded. I say "upgrade" but don't mean an > upgrade of Solr itself, I mean new/updated plugins (JARs) and an updated > configset specifies classes in those JARs. Thus the configset & Solr > software must be launched as a whole, definitely not Solr first using an > older ConfigSet in ZooKeeper that might contain references to > classes/configuration that no longer work. IMO users should become more > familiar with FileSystemConfigSetService, which I helped make pluggable to > address this conundrum. It needs more documentation, and there are > trade-offs (like mutable configsets / config-edit API will no longer be > practical). It's not going to be appropriate for everyone. If Solr's CLI > scripts cease supporting direct ZK communication, a user could use the ZK > CLI capability built-into zookeeper.jar that we used to provide a simple > shell script for. I don't know what happened to that; I just looked for it > without success. > > Solr can upload one configset on startup very early (before cores load) > -Dboostrap_confdir=/path/myname/conf/ -Dcollection.configName=myname (9.x > names; have changed in 10.x) which I recall isn't documented. I'm using > that now to avoid an explicit upload step for a Solr docker image used in > testing. > > > On Wed, May 13, 2026 at 6:56 AM David Eric Pugh via dev <[email protected]> > wrote: > > > Gus, when you say "node for solr", are you referencing the ZK Root [1]? > > That is also created at runtime I believe as well. > > Jan, thanks for sharing the operator perspective! Security.json doesn't > > have to be there before Solr starts, though of course we've seen our > > travails on that, and of course maybe not having it in ZK at all. The SSL > > cluster prop is another example of something thing we have to deal with. > > David, was the cluster prop around what http protocol to use? I do know > > that configsets don't have to be loaded first, just start up empty solr, > > add them, and then generate collections! > > What I am hearing is that there are some cluster level settings that we > > have to get right, but that we already seem to have pretty robust support > > for collection level configuration. > > I would very much like to see ZK become a implementation detail! The > > work on "solrConnection" string support will remove the need to specify > > zkHost in many places (streaming, cli), and help wean us off of thinking > > about ZK as something we interact with directly. > > Maybe a better way to ask this question: In the Solr CLI, what functions > > can/must operate directly on ZK (and require you to have direct access) > > versus being mediated through a Solr REST API? We have a hodge podge of > > different access mechnisms. "bin/solr zk" commands do seem like they > > should go to ZK, but outside of that? > > > > > > > > > > [1] > > https://solr.apache.org/guide/solr/latest/deployment-guide/taking-solr-to-production.html#zookeeper-chroot > > On Tuesday, May 12, 2026 at 08:22:14 PM EDT, David Smiley < > > [email protected]> wrote: > > > > In recent years, I recall > > 1. adding a cluster property (albeit wasn't SSL; I forget what for) > > 2. adding configsets > > > > On Tue, May 12, 2026 at 8:15 AM David Eric Pugh via dev < > > [email protected]> > > wrote: > > > > > 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]
