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.da...@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.hatc...@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.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 >> >
