lucene-solr-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Erick Erickson <erickerick...@gmail.com>
Subject Re: Testing Solr configuration, schema, and other fields
Date Thu, 31 Dec 2015 16:44:32 GMT
Hmmm, a couple of things:

the bin/solr script could be used as a model in this scenario for
how to automate a lot of this. I'm thinking you can skip all the
argument parsing and that and just see how the SolrCLI jar file
is used to spin up collections, upload configs and the like. In fact,
assuming a unique collection name per developer you could
use a common dev SolrCloud setup for this.

Or heck, perhaps just use the bin/solr script for all of that...

The other thing I was assuming is that you don't _really_ care
about starting/stopping Solr, it's more the requirement for your
devs to upload the configs, reload a collection, find out whether
the collection is running or not, if not find the log files and see why
cycle you'd like to shorten....

FWIW,
Erick

On Thu, Dec 31, 2015 at 8:31 AM, Davis, Daniel (NIH/NLM) [C]
<daniel.davis@nih.gov> wrote:
> 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