[jira] [Comment Edited] (SOLR-7316) API to create a core is broken

["Mark Haase (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/SOLR-7316?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14385497#comment-14385497 ] 

Mark Haase edited comment on SOLR-7316 at 3/28/15 7:31 PM:
-----------------------------------------------------------

Shawn, thanks for updating the doc, it is much clearer now that the conf directory must be set up before making the API call. 

{quote}
In the general non-cloud case, where is the config going to come from? A core cannot be created if it doesn't have a config, so you need a mechanism to provide it.
{quote}

I realize this problem is obvious to you, but you're a Solr expert. I'm not. I'm a normal user, like many, many of the other normal users out here.

I have no idea where the config comes from, nor do I care. Lots of servers come with a default config that can be used when the user doesn't specify one. If the documentation doesn't say I need one, then I assume that I don't need one. When I call an HTTP API, I expect that success does not depend on me having filesystem access to the host machine or having intimate knowledge of the structure of the /conf directory.

I can SSH into the machine to set up conf files, but at that point I'd rather just run `solr create -c foo`. It's easy, only takes one step, and doesn't require me to have any knowledge of how Solr works under the hood. That's the whole point of abstraction, right?!

I see that `solr create -c foo` actually does use the HTTP API, so clearly there is a need for it. That's why I suggested that it should be marked PRIVATE, as in, don't use this API unless you really know what you're doing. Normal people should use `solr create -c foo` or should move to cloud mode.

Better yet, split this into 2 APIs. One API is REGISTER and it takes an existing /conf dir and registers it as a new core — it does not have a configSet argument. The other is CREATE and it _requires a configSet argument_ so that it can truly create a core without the caller having to escalate privileges and do a magical dance.

The most annoying thing by far about tis API is that, Solr does include a perfectly good default configuration in "basic_configs". In fact, when you use `solr create -c foo`, IT USES THAT DEFAULT CONFIGURATION! So why doesn't the CREATE API also use the same default configuration? What's the huge difference?

All of you guys that are Solr experts, please take a step back and see this through the eyes of somebody who's not tracking every single 0.0.1 release or every single commit on master. I am only following the instructions in the Solr wiki: I downloaded a ZIP, ran the installer, and I want to run a single node. And guess what? It's been a total pain in my ass at every single step along the way, and everytime I ask a question the reply is basically, "well duh WTF are you doing that for?" It's frustrating and insulting. 


was (Author: mehaase):
Shawn, thanks for updating the doc, it is much clearer now that the conf directory must be set up before making the API call. 

{quote}
In the general non-cloud case, where is the config going to come from? A core cannot be created if it doesn't have a config, so you need a mechanism to provide it.
{quote}

I realize this problem is obvious to you, but you're a Solr expert. I'm not. I'm a normal user, like many, many of the other normal users out here.

I have no idea where the config comes from, nor do I care. Lots of servers come with a default config that can be used when the user doesn't specify one. The documentation doesn't say I need one, so I assume that I don't need one. When I call an HTTP API, I expect that success does not depend on me having filesystem access to the host machine or having intimate knowledge of the structure of the /conf directory.

I can SSH into the machine to set up conf files, but at that point I'd rather just run `solr create -c foo`. It's easy, only takes one step, and doesn't require me to have any knowledge of how Solr works under the hood. That's the whole point of abstraction, right?!

I see that `solr create -c foo` actually does use the HTTP API, so clearly there is a need for it. That's why I suggested that it should be marked PRIVATE, as in, don't use this API unless you really know what you're doing. Normal people should use `solr create -c foo` or should move to cloud mode.

Better yet, split this into 2 APIs. One API is REGISTER and it takes an existing /conf dir and registers it as a new core — it does not have a configSet argument. The other is CREATE and it _requires a configSet argument_ so that it can truly create a core without the caller having to escalate privileges and do a magical dance.

The most annoying thing by far about tis API is that, Solr does include a perfectly good default configuration in "basic_configs". In fact, when you use `solr create -c foo`, IT USES THAT DEFAULT CONFIGURATION! So why doesn't the CREATE API also use the same default configuration? What's the huge difference?

All of you guys that are Solr experts, please take a step back and see this through the eyes of somebody who's not tracking every single 0.0.1 release or every single commit on master. I am only following the instructions in the Solr wiki: I downloaded a ZIP, ran the installer, and I want to run a single node. And guess what? It's been a total pain in my ass at every single step along the way, and everytime I ask a question the reply is basically, "well duh WTF are you doing that for?" It's frustrating and insulting. 

> API to create a core is broken
> ------------------------------
>
>                 Key: SOLR-7316
>                 URL: https://issues.apache.org/jira/browse/SOLR-7316
>             Project: Solr
>          Issue Type: Bug
>          Components: Server
>    Affects Versions: 5.0
>            Reporter: Mark Haase
>
> *Steps To Reproduce*
> {code}
> curl 'http://localhost:8983/solr/admin/cores?action=CREATE&name=new_core&instanceDir=new_core'
> {code}
> *Expected Result*
> Create a core called "new_core".
> *Actual Result*
> {quote}
> 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'
> {quote}
> Somebody on solr-users tells me:
> {quote}
> The CoreAdmin API requires that the instanceDir already exist, with a
> conf directory inside it that contains solrconfig.xml, schema.xml, and
> any other necessary config files.
> {quote}
> Huh? Where is this magical knowledge mentioned in the [API documentation|https://cwiki.apache.org/confluence/display/solr/CoreAdmin+API]?
> Another user on the list serve says:
> {quote}
> 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.
> {quote}
> *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?* I'm speechless.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org