You are viewing a plain text version of this content. The canonical link for it is here.
Posted to solr-user@lucene.apache.org by Steven Bower <sm...@alcyon.net> on 2015/05/22 03:24:18 UTC

SolrCloud with local configs

Is it possible to run in "cloud" mode with zookeeper managing
collections/state/etc.. but to read all config files (solrconfig, schema,
etc..) from local disk?

Obviously this implies that you'd have to keep them in sync..

My thought here is of running Solr in a docker container, but instead of
having to manage schema changes/etc via zk I can just build the config into
the container.. and then just produce a new docker image with a solr
version and the new config and just do rolling restarts of the containers..

Thanks,

Steve

Re: SolrCloud with local configs

Posted by Shawn Heisey <ap...@elyograg.org>.
On 5/21/2015 7:24 PM, Steven Bower wrote:
> Is it possible to run in "cloud" mode with zookeeper managing
> collections/state/etc.. but to read all config files (solrconfig, schema,
> etc..) from local disk?
> 
> Obviously this implies that you'd have to keep them in sync..
> 
> My thought here is of running Solr in a docker container, but instead of
> having to manage schema changes/etc via zk I can just build the config into
> the container.. and then just produce a new docker image with a solr
> version and the new config and just do rolling restarts of the containers..

As far as I am aware, this is not possible.  As I think about it, I'm
not convinced that it's a good idea.  If you're going to be using
zookeeper for ANY purpose, the config should be centralized in zookeeper.

The ZK chroot (or new ZK ensemble, if you choose to go that route) will
be dedicated to that specific cluster.  It won't be shared with any
other cluster.  Any automation you've got that fires up a new cluster
can simply upload the cluster-specific config into the new ZK chroot as
it builds the container(s) for the cluster.  Teardown automation can
delete the chroot.

The idea is probably worth an issue in jira.  I won't veto the
implementation, but as I said above, I'm not yet convinced that it's a
good idea -- ZK is already in use for the clusterstate, using it for the
config completely eliminates the need for config synchronization.  Do
you have a larger compelling argument?

Thanks,
Shawn