: Clearly this won't be done in 8.x. I think it would be ok to make the
: switch in Solr 9, but maybe it's something we aim for Solr 10 instead. In
: the meantime we should probably include a backwards-compatible standalone
: flag (-l/-standalone) that will start to be used once the default mode is
: switched.

It's not clear to me what exactly you are suggesting the new "default" 
option should do w/regard to ZooKeeper?

Jan's response seems to assume that you are suggesting that the default 
behavior in Solr 9.x shold be equivilent to 8.x's "-c" (w/o a "-z" option) 
so that solr starts an embedded zookeeper ... this seems like a really bad 
idea to me, because it would "normalize" and encourage using the (non 
fault tollerant) embedded zookeeper even more then it already is in 8.x 
... not to mention that anyone trying to *ACTUALLY* run a (mult-node) 
"solr cluster" will still have to use "-z PORT_FROM_FIRST_SOLR_NODE" ... 
at least right now with the mandatory "-c" option anyone looking for how 
to start up a "cluster" can see the docs for "-c" pointing out hte 
importance of "-z"

On the otherhand: A differnet way of interpreting your suggestion is that 
if we're changing the command line args, and eliminating "-c" (because ow 
it's the default) we can start making "-z" required unless you specifying 
"-standalone" ... or some new "-run-single-point-of-failure-embedded-zk" 
so that solr defaults to cloud mode, but also deaults to failing fast if 
you don't have a zk cluster running (or know that you are doing something 
unsupported in production)

Jan's interpretation of your suggestion scares me, but i could get on 
board the second interpretation of pushing forward cloud mode and trying 
to make people more aware of the importance of a zk cluster.

(W/o more concrete specifics, I'm sure there are other interpretations of 
this suggestion as well, these are just the 2 that immediately popped to 
mind)



-Hoss
http://www.lucidworks.com/

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to