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

Alan Woodward commented on SOLR-5434:
-------------------------------------

Thinking further, maybe an even nicer way to start things up would be to have a 
default new-style solr.xml that can be overridden by environment variables.  
Then you just tell new users to start solr up with -DzkRun 
-Dsolr.solr.home=/path/to/where/I/want/data/stored, and it should Just Work.  
No need to copy example directories anywhere.

> Create minimal solrcloud example directory
> ------------------------------------------
>
>                 Key: SOLR-5434
>                 URL: https://issues.apache.org/jira/browse/SOLR-5434
>             Project: Solr
>          Issue Type: Improvement
>            Reporter: Alan Woodward
>            Assignee: Alan Woodward
>            Priority: Minor
>             Fix For: 4.6, 5.0
>
>
> The various "intro to solr cloud" pages (for example 
> https://cwiki.apache.org/confluence/display/solr/Getting+Started+with+SolrCloud)
>  currently tell new users to use the example/ directory as a basis for 
> setting up new cloud instances.  These directories contain, under the default 
> solr/ solr home directory, a single core, defined to point to the collection1 
> collection.
> It's not at all obvious that, to change the name of your collection, you have 
> to go and edit the core.properties file underneath the solr/ directory.  A 
> lot of users on the mailing list also seem to get confused by having to 
> include bootstrap_confdir and numShards the first time they run solr, but not 
> afterwards.  So here's a suggestion:
> * Have a new solrcloud/ directory in the example webapp that just contains a 
> solr.xml file
> * Change the startup example code to just include -Dsolr.solr.home and -DzkRun
> * Tell the user to then run zkcli to bootstrap their configuration (solr 
> startup and configuration loading are kept separate)
> * Tell the users to use the collections API to create a new collection, 
> naming it however they want (confignames, collection names and core names are 
> all kept separate)
> This way, there's a lot less 'magic' and hidden defaults involved, and all 
> the steps to get a cloud up and running (start processes, upload 
> configuration, create collection) are made distinguishable.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

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

Reply via email to