Hi,
On Mon, Sep 30, 2019 at 3:59 PM Ishan Chattopadhyaya <
ichattopadhy...@gmail.com> wrote:
> Hi,
> I think some of us feel that
> SolrCloud or "cloud mode" etc. are misnomers. This name sometimes trips up
> many adopters.
>
> I propose that we rename SolrCloud mode to "cluster mode" such that
>
On 20/10/2019 01:32, Noble Paul wrote:
> A standalone mode should be nothing but a SolrCloud setup with an
> embedded ZK and a single node.
From an operations point of view, I disagree. ZK is another process to
monitor, another process which can fail, another process which exposes
various security
A standalone mode should be nothing but a SolrCloud setup with an
embedded ZK and a single node.
If users want to edit config files they can still do it . People edit
config files all the time in SolrCloud today. Directly editing files
on a filesystem cannot be a requirement that keeps as from mov
On 10/17/2019 10:58 AM, David Smiley wrote:
Some ideas:
* Add a config file editor to Solr. Not sure if our APIs are sufficient
here; don't want to add another security risk.
It would be VERY useful to have this. It should require explicit admin
action to enable -- not enabled by default, o
Unfortunately, I think SolrCloud / cluster mode is less easy to use than
standalone mode for the developer experience locally. The main pain point
is the ease of modifying configuration. In standalone, I go edit some
configs using a text editor, then hit "reload" on the core. Presto. With
the c
Solr can run Zookeeper embedded. Just make the 'standalone' version run a
Zookeeper, then you can deprecate the standalone mode entirely.
Also, given that installing ZooKeeper is a pain, and that Solr has the embedded
ability to run ZooKeeper, it always seemed a good idea to me to have the optio
I agree very much on normalizing to one mode of running Solr
So long as the 'cluster mode' hello world is easier than having to think a
lot about zookeeper and other hard things. One reason people use standalone
mode because it's as simple as "Point '/bin/solr' at config directory and
go". If ther
Jan,
I agree strongly with your last point. And in case you haven't seen it
before, there is a solr k8s operator, with a growing community, under
development at https://github.com/bloomberg/solr-operator.
I agree that taking control of the solr docker images could be a good idea.
That way, it cou
Why even "cluster mode" or "cloud mode"?
Solr, by default , should use the cluster mode. So in all our
documentation, we should use just "Solr" and it should refer to a
"cluster mode of Solr"
Wherever we don't have a "cluster mode" should be explicitly qualified
as "standalone Solr"
On Wed, Oct
+1 to adapting all our docs to make cluster mode the preferred/default and
“hide” the standalone use cases more. We could also redefine -c in start script
to mean “cluster”?
Instead of getting rid of the SolrCloud term, why not strive for making Solr
more “cloud native”, and thus live up to the
I hear you and sympathize but "SolrCloud" has been used long enough that I
doubt the trouble is worth it. I guess that makes me "+0". That said, I
think it wouldn't hurt to formalize "standalone mode" as-such and perhaps
say more explicitly that SolrCloud == "cluster mode" even if we don't
elimin
On 9/30/2019 6:59 AM, Ishan Chattopadhyaya wrote:
I propose that we rename SolrCloud mode to "cluster mode" such that
there shall be "Apache Solr", running in either "standalone mode" or
"cluster mode". We can effect this renaming 9.0 onwards, if we have
consensus.
I am open to any other proposa
Hi,
I think some of us feel that
SolrCloud or "cloud mode" etc. are misnomers. This name sometimes trips up
many adopters.
I propose that we rename SolrCloud mode to "cluster mode" such that
there shall be "Apache Solr", running in either "standalone mode" or
"cluster mode". We can effect this ren
13 matches
Mail list logo
