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 17:02:59 GMT
That's incredibly cool.   Much easier than the chef/puppet scripts and stuff I've seen.   
I'm certain to play with this and get under the hood; however, we locally don't have a permission
to use AWS EC2 in this corner of NLM.    There's some limited use of S3 and Glacier.   Maybe
we'll negotiate EC2 for dev later this year, maybe not.
 
-----Original Message-----
From: Alexandre Rafalovitch [mailto:arafalov@gmail.com] 
Sent: Thursday, December 31, 2015 11:40 AM
To: solr-user <solr-user@lucene.apache.org>
Subject: Re: Testing Solr configuration, schema, and other fields

Makes sense.

Answering the answer email in this thread, did you look at Solr Scale?
Maybe it has the base infrastructure you need:
https://github.com/LucidWorks/solr-scale-tk

Regards,
   Alex.
----
Newsletter and resources for Solr beginners and intermediates:
http://www.solr-start.com/


On 31 December 2015 at 23:37, Davis, Daniel (NIH/NLM) [C] <daniel.davis@nih.gov> wrote:
>> What is the next step you are stuck on?
>>
>> Regards,
>>    Alex
>
> I'm not really stuck.   My question has been about the best practices.   I am trying
to work against "not-invented-here" syndrome, "only-useful-here" syndrome, and "boil-the-ocean"
syndrome.    I have to make the solution work with a Continuous Integration (CI) environment
that will not be creating either docker images or VMs for each project, and so I've been seeking
the wisdom of the crowd.
>
> -----Original Message-----
> From: Alexandre Rafalovitch [mailto:arafalov@gmail.com]
> Sent: Thursday, December 31, 2015 12:42 AM
> To: solr-user <solr-user@lucene.apache.org>
> Subject: Re: Testing Solr configuration, schema, and other fields
>
> I might be just confused here, but I am not sure what your bottle neck actually is. You
seem to know your critical path already, so how can we help?
>
> Starting new solr core from given configuration directory is easy. Catching hard errors
from that is probably just gripping logs or a custom logger.
>
> And you don't seem to be talking about lint style soft sanity checks, but rather the
initialization stopping hard checks.
>
> What is the next step you are stuck on?
>
> Regards,
>    Alex
> On 31 Dec 2015 3:09 am, "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