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

Eric Pugh commented on SOLR-16254:
----------------------------------

[~sunrui] thanks for opening this ticket.  I just stumbled across your issue, 
and if you are interested in working on this one to get it to done, I'd be 
happy to work with you, just let me know!

There has been a lot of work on the CLI, including in Main the merging of 
create_core and create_collection into just a "create" command.    

I looked a bit at the code 
([https://github.com/apache/solr/blob/branch_9x/solr/core/src/java/org/apache/solr/cli/CreateTool.java#L174)]
 and the difference between the API command and CreateTool.java is that 
CreateTool assumes you are working in a local server environment, and that you 
NEED to muck around with files.    Then it calls the API.

Whereas, just using the API, you don't get to muck around with the files.

It seems like the logic for creating a core could be smarter to understand when 
you want to create a core and are running remotely and therefore do NOT have 
access to the filesystem.   Basically be smarter about looking for 
System.getProperty("solr.install.dir") and deciding "hey, you need this 
directory and are running remote, raise a nice error" or b) if you don't need 
this property for what you are doing, then let it thorugh. 

I don't have a clear sense of how many folks running a user managed 
(standalone) Solr would ever want to run this command remotely?

> solr standalone: in-correct information in the help message for "bin/solr 
> create_core"
> --------------------------------------------------------------------------------------
>
>                 Key: SOLR-16254
>                 URL: https://issues.apache.org/jira/browse/SOLR-16254
>             Project: Solr
>          Issue Type: Bug
>          Components: cli
>    Affects Versions: 9.0
>            Reporter: Sun Rui
>            Priority: Major
>
> There is a statement in the help message for "bin/solr create_core":
> _*When a configSet is used, this can be run from remote (non-Solr) hosts.  If 
> pointing at a non-configSet directory, this must be run from the host that 
> you wish to create the core on.*_
> However, this is not case.
> Suppose there is a solr server instance launched at 192.168.0.100:8983. On a 
> different host (non-solr host), use the following command to create a new 
> core:
> SOLR_HOST=192.168.0.100 bin/solr create_core -c test -d _default -p 8983
> an error message is output like the following:
> ERROR: Error CREATEing SolrCore 'test': Unable to create core [test] Caused 
> by: Can't find resource 'solrconfig.xml' in classpath or '/var/solr/data/test'
> check the core status:
> $ curl [http://192.168.0.100:8983/solr/admin/cores]
> {
>   "responseHeader":
> {     "status":0,     "QTime":0}
> ,
>   
> "initFailures":\{"test":"org.apache.solr.common.SolrException:org.apache.solr.common.SolrException:
>  Could not load conf for core test: Error loading solr config from 
> /opt/solr-9.0.0/server/solr/test/conf/solrconfig.xml"},
>   "status":{}}
> You can see that the core was created but can't be loaded by the solr server 
> (because of no configuration files can be found in the conf sub-directory of 
> the instance directory).
> As a comparison, we can remotely create a new core using the following Solr 
> API:
> curl 
> "http://192.168.0.100:8983/solr/admin/cores?action=CREATE&name=test&instanceDir=test&configSet=_default";
>  
> My question is how to fix this issue. Do we want to fixup the statement to 
> match the real behavior or update the create_core tool to support remotely 
> creating a core ?



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to