[
https://issues.apache.org/jira/browse/BIGTOP-779?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14287751#comment-14287751
]
Roman Shaposhnik commented on BIGTOP-779:
-----------------------------------------
[~jayunit100] would be more than happy to on-board you to what I [used] to
know. That said, I am sure there was tons of development since I last touched
SolrCloud. Perhaps [[email protected]] can shed some light on the latest
in SolrCloud land. For example, I'd be curious to know if we're any closer to
the deployment model, where any Solr is SolrCloud (IOW a regular Solr is a
SolrCloud of one). Things like that.
> create a config management utility for SolrCloud
> ------------------------------------------------
>
> Key: BIGTOP-779
> URL: https://issues.apache.org/jira/browse/BIGTOP-779
> Project: Bigtop
> Issue Type: Improvement
> Components: general
> Affects Versions: 0.5.0
> Reporter: Roman Shaposhnik
> Assignee: Roman Shaposhnik
> Priority: Blocker
> Fix For: backlog
>
>
> Currently we have an extremely confusing situation with SolrCloud
> configuration management. SolrCloud expects its collection configs to be
> available in Zookeeper and treats the configs in the local file system as
> seed for the ZK copy only.
> Thus we have an unfortunate situation where an unsuspecting sysadm will
> happily modify settings under /etc/solr/conf/<collection>/ and be very
> frustrated by SolrCloud not taking the values in.
> NOTE1: as I mentioned -- this only applies to collection configs. For example
> /etc/solr/conf/solr.xml is fine.
> NOTE2: also note, that even though in Bigtop context SolrCloud configuration
> makes more sense than a standalone Solr server it is completely possible for
> folks to run Solr in a standalone mode as well. In which case you *have* to
> have local configuration files under /etc/solr/conf/<collection>/ since ZK is
> not being used.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
