metron-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dale Richardson (Jira)" <j...@apache.org>
Subject [jira] [Updated] (METRON-2312) Solr collection create/delete scripts assume they are not in a chrooted environment by default
Date Wed, 13 Nov 2019 05:42:00 GMT

     [ https://issues.apache.org/jira/browse/METRON-2312?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Dale Richardson updated METRON-2312:
------------------------------------
    Description: 
When installing SOLR cloud, its been highly recommended to use the cluster zookeeper ensemble
rather then installing your in own mini-zk cluster just for SOLR.  For the past several years,
its been standard practice to use a chrooted / namespaced environment for storing solr information
in zookeeper.   The practical effects of this is to need to prepend '/solr' to any zookeeper
ensemble URLs.  The use of chrooted zookeeper configurations is the default in both lucidworks/HWX
SOLR (from 4.0), and for Cloudera SOLR (not sure which version but for many years).  It has
also been the documented recommendation for Apache SOLR Cloud since approximately version
6.6.

End result is, if Metron is dealing with a SOLR cluster that has been installed or updated
any time in the past couple of years, it is dealing with a SOLR configuration stored in a
chrooted Zookeeper environment.  

The problem is the Metron SOLR collection create/destroy scripts assume that we are not using
a CHROOTed environment, and fail badly when the expected SOLR configuration is not present
at the expected location in SOLR.  Buried in the readme is instruction on how to set modify
the zookeeper environment variables before running the script to add chrooted address, and
when the scripts are used by Ambari, they are called using the correct chrooted quorum URL,
because they is a seperate configuration item that can be set to indicate the chroot zookeeper
address for SOLR.

Having just been burnt by this I think we should at least
 # Cleanly catch the failure of the zkcli command in the collection scripts when it queries
for zookeeper state that is not present
 # If the zkcli error is caught, make a suggestion in the error message to check for a chrooted
SOLR cloud zookeeper configuration.

 

 

  was:
When installing SOLR cloud, its been highly recommended to use the cluster zookeeper ensemble
rather then installing your in own mini-zk cluster just for SOLR.  For the past several years,
its been standard practice to use a chrooted / namespaced environment for storing solr information
in zookeeper.   The practical effects of this is to need to prepend '/solr' to any zookeeper
ensemble URLs.  The use of chrooted zookeeper configurations is the default in both lucidworks/HWX
SOLR (from 4.0), and for Cloudera SOLR (not sure which version but for many years).  It has
also been the documented recommendation for Apache SOLR Cloud since approximately version
6.6.

End result is, if Metron is dealing with a SOLR cluster that has been installed or updated
any time in the past couple of years, it is dealing with a SOLR configuration stored in a
chrooted Zookeeper environment.  

The problem is the Metron SOLR collection create/destroy scripts assume that we are not using
a CHROOTed environment, and fail badly when the expected SOLR configuration is not present
at the expected location in SOLR.  Buried in the readme is instruction on how to set modify
the zookeeper environment variables before running the script, and when the scripts are used
by Ambari, they are called using the correct chrooted quorum URL.

 

 


> Solr collection create/delete scripts assume they are not in a chrooted environment by
default
> ----------------------------------------------------------------------------------------------
>
>                 Key: METRON-2312
>                 URL: https://issues.apache.org/jira/browse/METRON-2312
>             Project: Metron
>          Issue Type: Bug
>            Reporter: Dale Richardson
>            Assignee: Dale Richardson
>            Priority: Major
>
> When installing SOLR cloud, its been highly recommended to use the cluster zookeeper
ensemble rather then installing your in own mini-zk cluster just for SOLR.  For the past
several years, its been standard practice to use a chrooted / namespaced environment for storing
solr information in zookeeper.   The practical effects of this is to need to prepend '/solr'
to any zookeeper ensemble URLs.  The use of chrooted zookeeper configurations is the default
in both lucidworks/HWX SOLR (from 4.0), and for Cloudera SOLR (not sure which version but
for many years).  It has also been the documented recommendation for Apache SOLR Cloud since
approximately version 6.6.
> End result is, if Metron is dealing with a SOLR cluster that has been installed or updated
any time in the past couple of years, it is dealing with a SOLR configuration stored in a
chrooted Zookeeper environment.  
> The problem is the Metron SOLR collection create/destroy scripts assume that we are not
using a CHROOTed environment, and fail badly when the expected SOLR configuration is not present
at the expected location in SOLR.  Buried in the readme is instruction on how to set modify
the zookeeper environment variables before running the script to add chrooted address, and
when the scripts are used by Ambari, they are called using the correct chrooted quorum URL,
because they is a seperate configuration item that can be set to indicate the chroot zookeeper
address for SOLR.
> Having just been burnt by this I think we should at least
>  # Cleanly catch the failure of the zkcli command in the collection scripts when it queries
for zookeeper state that is not present
>  # If the zkcli error is caught, make a suggestion in the error message to check for
a chrooted SOLR cloud zookeeper configuration.
>  
>  



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

Mime
View raw message