Hmmm, looks like I stand corrected. I haven't kept complete track there, looks like this one didn't stick in my head.
As far as the docs are concerned, all patches welcome! Best, Erick On Thu, Mar 26, 2015 at 10:26 AM, Mark E. Haase <meha...@gmail.com> wrote: > Erick, are you sure that configSets don't apply to single-node Solr > instances? > > https://cwiki.apache.org/confluence/display/solr/Config+Sets > > I don't see anything about Solr cloud there. Also, "configSet" is a > documented argument to the Core Admin API: > > https://cwiki.apache.org/confluence/display/solr/CoreAdmin+API#CoreAdminAPI-CREATE > > And one of the few things [I thought] I knew about "cloud" vs "non cloud" > setups was the Collections API is for cloud and Cores API is for non cloud, > right? So why would the non-cloud API take a cloud-only argument? > > On Thu, Mar 26, 2015 at 1:16 PM, Mark E. Haase <meha...@gmail.com> wrote: > >> Okay, thanks for the feedback. I'll admit that I do find the cloud vs >> non-cloud deployment options a constant source of confusion, not the least >> of which is due to the name. If I run a single Solr instance on EC2, that's >> not "cloud", but if I run a few instances with ZK on my local LAN, that is >> "cloud". Mmmkay. >> >> I can't imagine why the API documentation wouldn't mention that the API >> can't actually do the thing it's supposed to do (create a core). What's the >> purpose of having an HTTP API if I'm expected to already have write access >> to the host's file system to use it? Maybe its intended as private API? It >> should only be used by Solr itself, e.g. `solr create -c foo` uses the >> Cores Admin API to do some (but not all) of its work. But if that's the >> case, then the API docs should say that. >> >> From an API consumer's point of view, I'm not really interested in being >> forced to learn the history of the project to use the API. The whole point >> of creating APIs is to abstract out details that the caller doesn't need to >> know, and yet this API requires an understanding of Solr's internal file >> structure and history of the project? >> >> Yikes. >> >> >> On Thu, Mar 26, 2015 at 12:56 PM, Erick Erickson <erickerick...@gmail.com> >> wrote: >> >>> Ok, you're being confused by cloud, non cloud and all that kinda stuff.... >>> >>> Configsets are SolrCloud only, so forget them since you specified it's >>> not SolrCloud. >>> >>> bq: surely the HTTP API doesn't require the caller to create a >>> directory and copy files first, does it >>> >>> In fact, yes. The thing to remember here is that you're using a much >>> older approach that had its roots in the pre-cloud days. The problem >>> is how do you insure that the configurations are on the node you're >>> creating the core on? The whole configsets discussion is an attempt to >>> solve that in SolrCloud by putting the configs in a place any Solr >>> instance can find them, namely Zookeeper. >>> >>> But in non-cloud, there's no central repository. You could be firing >>> the query from node X and creating the core on node Y. So Solr expects >>> the config files to already be in place; you have to manually copy >>> them to node Y anyway, why not copy them to the place they'll be >>> needed? >>> >>> The scripts make an assumption that you're running on the same node >>> you're running the scripts for quick-start purposes. >>> >>> Best, >>> Erick >>> >>> On Thu, Mar 26, 2015 at 9:24 AM, Mark E. Haase <meha...@gmail.com> wrote: >>> > I can't get the Core Admin API to work. I have a brand new installation >>> of >>> > Solr 5.0.0 (in non-cloud mode). I installed using the installation >>> script >>> > (a nice addition!) with default options, so I have Solr in /opt/solr and >>> > its data in /var/solr. >>> > >>> > Here's what I'm trying: >>> > >>> > curl ' >>> http://localhost:8983/solr/admin/cores?action=CREATE&name=new_core >>> > ' >>> > >>> > But I get this error: >>> > >>> > Error CREATEing SolrCore 'new_core': Unable to create core >>> [new_core] >>> > Caused by: Can't find resource 'solrconfig.xml' in classpath or >>> > '/var/solr/data/new_core/conf' >>> > >>> > Solr isn't even creating /var/solr/data/new_core, which I guess is the >>> root >>> > of the problem. But /var/solr is owned by the solr user and I can do >>> `sudo >>> > -u solr mkdir /var/solr/data/new_core` just fine. So why isn't Solr >>> making >>> > this directory? >>> > >>> > I see that 'instanceDir' is required, but I don't get an error message >>> if I >>> > *don't* use it, so I'm not sure how required it actually is. I'm also >>> not >>> > sure if its supposed to be a full path or a relative path or what, so >>> here >>> > are a couple of other guesses at the correct incantation: >>> > >>> > curl ' >>> > >>> http://localhost:8983/solr/admin/cores?action=CREATE&name=new_core&instanceDir=new_core >>> > ' >>> > curl ' >>> > >>> http://localhost:8983/solr/admin/cores?action=CREATE&name=new_core&instanceDir=/var/solr/data/new_core >>> > ' >>> > >>> > These both return the same error message as my first try, so no dice... >>> > >>> > FWIW, I get the same error message even if I try doing this with the >>> Solr >>> > Admin GUI so I'm really puzzled. Is the GUI supposed to work? >>> > >>> > I found a thread on Stack Overflow about this same problem ( >>> > http://stackoverflow.com/a/28945428/122763) that suggests using >>> configSet. >>> > Okay, the installer put some configs sets in >>> > /opt/solr/server /opt/solr/server/solr/configsets, and the >>> 'basic_config' >>> > config set has a solrconfig.xml in it, so maybe that would solve my >>> > solrconfig.xml error? >>> > >>> > If I compare the HTTP API to the `solr create -c foo` script, it appears >>> > that the script creates the instance directory and copies in conf files >>> *before >>> > *it calls the HTTP API... surely the HTTP API doesn't require the >>> caller to >>> > create a directory and copy files first, does it? >>> > >>> > -- >>> > Mark E. Haase >>> >> >> >> >> -- >> Mark E. Haase >> 202-815-0201 >> > > > > -- > Mark E. Haase > 202-815-0201
