[
https://issues.apache.org/jira/browse/SOLR-7316?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14385568#comment-14385568
]
Mark Haase edited comment on SOLR-7316 at 3/28/15 11:47 PM:
------------------------------------------------------------
{quote}
I would wager that this point of view will not survive beyond your first
production deployment. The expert users definitely care, and they do not want
that to be controlled by us, they want it to be controlled by them.
{quote}
Shawn, consider Apache Web Server.
* Does it come with a default config? Yes
* Does the default config serve a basic purpose: Yes, Apache is configured to
serve files over HTTP
* Would I typically take that default config to production? No
How about OpenSSH?
* Does it come with a default config? Yes
* Does the default config serve a basic purpose: Yes, OpenSSH is configured to
allow remote login
* Would I typically take that default config to production? No
How about Elastic Search?
* Does it come with a default config? Yes
* Does the default config serve a basic purpose: Yes, I can start indexing
documents and searching right away.
* Would I typically take that default config to production? Dunno, I haven't
taken ES into production. It's probably a "no" all the same.
I had never used Elastic Search up until a few minutes ago. In order to make a
point, I googled "elastic search installation", clicked the first result, and
followed the instructions. That was at 7:27 PM EST. By 7:33, I had index 3
documents in the tutorial and had performed several searches against those
documents.
Number of configuration files I need to be aware of: 0.
Now THAT'S an out-of-the-box experience. Wow.
How about Solr?
* Does it come with a default config? Yes and no; it depends on whether you're
logged into a shell or using the HTTP API.
* Does the default config serve a basic purpose: Yes, but only if you're using
the shell. HTTP API doesn't do anything OOTB.
* Would I typically take that default config to production? No, but if I could
manipulate the schema over HTTP, then yes!
Do you understand why I filed a bug report that the API is broken?
was (Author: mehaase):
{quote}
I would wager that this point of view will not survive beyond your first
production deployment. The expert users definitely care, and they do not want
that to be controlled by us, they want it to be controlled by them.
{quote}
Shawn, consider Apache Web Server.
* Does it come with a default config? Yes
* Does the default config serve a basic purpose: Yes, Apache is configured to
serve files over HTTP
* Would I typically take that default config to production? No
How about OpenSSH?
* Does it come with a default config? Yes
* Does the default config serve a basic purpose: Yes, OpenSSH is configured to
allow remote login
* Would I typically take that default config to production? No
How about Elastic Search?
* Does it come with a default config? Yes
* Does the default config serve a basic purpose: Yes, I can start indexing
documents and searching right away.
* Would I typically take that default config to production? Dunno, I haven't
taken ES into production. It's probably a "no" all the same.
I had never used Elastic Search up until a few minutes ago. In order to make a
point, I googled "elastic search installation", clicked the first result, and
followed the instructions. That was at 7:27 PM EST. By 7:33, I had index 3
documents in the tutorial and had performed several searches against those
documents.
Number of configuration files I need to be aware of: 0.
Now THAT'S an out-of-the-box experience. Wow.
How about Solr?
* Does it come with a default config? Yes and no; it depends on whether you're
logged into a shell or using the HTTP API.
* Does the default config serve a basic purpose: Yes, but only if you're using
the shell. HTTP API doesn't do anything OOTB.
* Would I typically take that default config to production? No, but if I could
manipulate the schema over HTTP, then yes!
> 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]
