lucene-solr-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Davis, Daniel (NIH/NLM) [C]" <daniel.da...@nih.gov>
Subject RE: Testing Solr configuration, schema, and other fields
Date Thu, 31 Dec 2015 16:31:58 GMT
Erik, that suggests an additional approach that seems to have "legs":
 
* A webapp that acts as a sort of Cloud IDE for Solr configsets.   It supports multiple projects
and a single SolrCloud cluster.   For each project, it upconfigs a git repository local to
the webapp, and has the ability to define tests that run against a "temporary" collection
to verify the configuration.

* A command-line utility that upconfigs the configuration a local directory, creates a temporary
collection, and supports an optional "tests" by applying an update query.

Since the webapp would be based on something like the command-line utility (maybe in library
form), I think I'm still going to target the command-line utility as my "minimum viable product".
  I'll support SolrCloud first, and then see about EmbeddedSolrServer.

-----Original Message-----
From: Erik Hatcher [mailto:erik.hatcher@gmail.com] 
Sent: Thursday, December 31, 2015 10:00 AM
To: solr-user@lucene.apache.org
Subject: Re: Testing Solr configuration, schema, and other fields

Dan - I’m a fan of the idea of using EmbeddedSolrServer for the type of thing you mention,
but since you’re already using SolrCloud how about simply upconfig’ing the configuration
from the Git repo, create a temporary collection using that configset and smoke test it before
making it ready for end client/customer/user use?   Maybe the configset and collection created
for smoke testing are just temporary in order to validate it.

—
Erik Hatcher, Senior Solutions Architect http://www.lucidworks.com <http://www.lucidworks.com/>



> On Dec 30, 2015, at 3:09 PM, Davis, Daniel (NIH/NLM) [C] <daniel.davis@nih.gov>
wrote:
> 
> At my organization, I want to create a tool that allows users to keep a solr configuration
as a Git repository.   Then, I want my Continuous Integration environment to take some branch
of the git repository and "publish" it into ZooKeeper/SolrCloud.
> 
> Working on my own, it is only a very small pain to note foolish errors I've made, fix
them, and restart.    However, I want my users to be able to edit their own Solr schema and
config *most* of the time, at least on development servers.    They will not have command-line
access to these servers, and I want to avoid endless restarts.
> 
> I'm not interested in fighting to maintain such a useless thing as a DTD/XSD without
community support; what I really want to know is whether Solr will start and can index some
sample documents.   I'm wondering whether I might be able to build a tool to fire up an EmbeddedSolrServer
and capture error messages/exceptions in a reasonable way.     This tool could then be run
by my users before they commit to git, and then again by the CI server before it "publishes"
the configuration to ZooKeeper/SolrCloud.
> 
> Any suggestions?
> 
> Dan Davis, Systems/Applications Architect (Contractor), Office of 
> Computer and Communications Systems, National Library of Medicine, NIH
> 

Mime
View raw message