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 >
