Well, I guess NIH stands for Not Invented Here. No idea what NLM is for. P.s. sorry, could not resist. I worked for orgs like that too :-( On 1 Jan 2016 12:03 am, "Davis, Daniel (NIH/NLM) [C]" <daniel.da...@nih.gov> wrote:
> 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:arafa...@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.da...@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:arafa...@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.da...@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 > >> > >> >
