Support only SolrCloud

[Varun Thacker <va...@vthacker.in>]

Hi Everyone,

After Solr 7.0 we support a master slave architecture in SolrCloud. I'd
expect more SolrJ support and follow up tasks as more people start using it.

Single node standalone Solr: You don't need to maintain a separate ZK
ensemble and can use the embedded ZK since it's just one node of Solr . The
only difference here would be the user having to upload configs to ZK
rather than residing on local disk. We already have "bin/solr zk" to make
this convenient and could enhance it more to make the transition smoother.

Master-Slave setup: There can only be one master so an embedded ZK will
work here as well. Again interacting with ZK for configs and not the local
file system. They would create collections instead of cores and use pull
replicas for slaves.

What are the possible benefits ?

   1. Consistent terminology : There will only be one way of running Solr .
   2. Cores become an underlying implementation and from we can start
   calling them replicas . Today SolrCloud users need to understand what cores
   are , can manipulate them through core api's
   3. Simpler setups : Today users have all sorts of ways of setting up
   solr . Have an instance directory , data directory , solr home. In a
   SolrCloud only world there would be ZK for configs and a data directory for
   indexes.

For a new user coming in today what will be reasons that he doesn't use
SolrCloud ?
If there is still a wide gap then we can punt this to a later timeframe .

Re: Support only SolrCloud

[Karl Wright <da...@gmail.com>]

ManifoldCF has an integration with SolrJ that allows configuration for both
Solr standalone and Solr Cloud selections.  While this change would
eventually simplify the UI and support requirements in the MCF Solr
connector in the long term, we could not get rid of it for years because we
maintain backwards compatibility with earlier versions of Solr.  It sounds
like that backwards compatibility would no longer be supported in SolrJ?

Also, FWIW, having a standalone, easily started instance of Solr is very
very useful for automated integration testing.  I presume there will still
be a straightforward way to do this?

Karl


On Mon, Dec 4, 2017 at 12:20 AM, Varun Thacker <va...@vthacker.in> wrote:

> Hi Everyone,
>
> After Solr 7.0 we support a master slave architecture in SolrCloud. I'd
> expect more SolrJ support and follow up tasks as more people start using it.
>
> Single node standalone Solr: You don't need to maintain a separate ZK
> ensemble and can use the embedded ZK since it's just one node of Solr . The
> only difference here would be the user having to upload configs to ZK
> rather than residing on local disk. We already have "bin/solr zk" to make
> this convenient and could enhance it more to make the transition smoother.
>
> Master-Slave setup: There can only be one master so an embedded ZK will
> work here as well. Again interacting with ZK for configs and not the local
> file system. They would create collections instead of cores and use pull
> replicas for slaves.
>
> What are the possible benefits ?
>
>    1. Consistent terminology : There will only be one way of running Solr
>    .
>    2. Cores become an underlying implementation and from we can start
>    calling them replicas . Today SolrCloud users need to understand what cores
>    are , can manipulate them through core api's
>    3. Simpler setups : Today users have all sorts of ways of setting up
>    solr . Have an instance directory , data directory , solr home. In a
>    SolrCloud only world there would be ZK for configs and a data directory for
>    indexes.
>
> For a new user coming in today what will be reasons that he doesn't use
> SolrCloud ?
> If there is still a wide gap then we can punt this to a later timeframe .
>