I completely agree with this. The default going forward should be to
separate the solr config files and the data directory.
It's very inconvenient in Kube that we have to go and copy the config files
everytime we start a pod.
We should be using the default solr.xml by default, and the docker image
Folks, please let me know what you think of my proposal below.
PROBLEM:
Today in Docker (and probably the Linux installer), the solr home dir in
/var/solr/... is initialized with solr.xml, zoo.cfg and log4j2.xml [1].
Consequently, if you deploy new Docker images of Solr with updated built-in
confi
Or to keep things fast without retaining all the checks, one could provide
slow/fast modes for test, fast requiring a local zookeeper external to the
tests, with the tests properly namespacing themselves... that does imply
reworking some tests.
Now that I say the above, it would be interesting if
Good call-out on perceived complexity due to running 3 ZK nodes. For many
small installations, honestly Solr's embedded ZK is fine. Also, again for
small installations, running ZK alongside Solr (same hardware) is fine. We
shouldn't needlessly shame users away from doing these things as if it's
I've met several clients who really didn't want to manage zookeeper as an
additional service (I've talked some into it anyway, but it was clearly a
key reason they hadn't started/gone cloud). I think it would be far more
palatable if it's all "part of solr", doesn't require plumbing the docs of
som
