[
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: [email protected]
For additional commands, e-mail: [email protected]
