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
