Thanks for sharing that... What about the bootstrap_conf? Would a path forward be to remove bootstrap_conf, and keep bootstrap_confdir, moving it to a better more consistent system property name?
I really wish we had a test for the bootstrap_confdir! One more thought, isn't there a way to add a script to your docker, maybe entrypoint.sh that runs after solr starts that would use bin/solr and enabled "all the things" that you might want? I looked and I see in our Docker set up a run-initdb that appears to set up /docker-entrypoint-initdb.d and so maybe a bin/solr upconfig could go there instead? On 2025/08/24 04:58:38 David Smiley wrote: > I've used bootstrap_confdir and env var DEFAULT_CONFDIR (as recently as > yesterday quite literally) for convenient ways of bootstrapping a custom > Docker image with one's own configset. In that scenario (embedded ZK), > it's awkward to attempt to use zkcli upconfig after Solr starts since > there's no hook/script to execute something after Solr starts. > > On Sat, Aug 23, 2025 at 9:58 PM Mark Miller <markrmil...@gmail.com> wrote: > > > These where system properties that allowed automated config set upload > > before better options came along. This was pre collection API or other > > scripts that let you upload a config set. They were probably largely added, > > like internal zk mode, for the “demo” - a series of commands on the wiki > > you could run to bring up a working cloud cluster without any other manual > > steps. > > > > I believe one of them let you specify a directory to upload and the other > > would look at solr.xml and upload the config sets for all configured cores. > > > > I believe this code was rooted in ZkController or maybe ZkContainer > > initially. I suppose for back compatibility, eventually support was moved > > to ConfigSetService. If they don't currently work, at some point they must > > have been broken. They are no longer mentioned in the docs, and the > > functionality they provided was long ago superseded by more modern options. > > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@solr.apache.org For additional commands, e-mail: dev-h...@solr.apache.org