[
https://issues.apache.org/jira/browse/SOLR-4662?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13620241#comment-13620241
]
Shawn Heisey commented on SOLR-4662:
------------------------------------
bq. There's no assumption when walking the tree that any instancedirs appear as
immediate children
That's good, and is awesome for detection of existing cores on startup, but
what about features that automatically create new core directories? This
already happens with the SolrCloud collection API, and if we implement the
configs directory for config sets that aren't stored in zookeeper, it is likely
to happen for non-Cloud deployments too.
I am aware that my statements may seem somewhat disconnected, because in some
ways they are. I'm dealing with two different Solr deployments that each have
their own needs.
1) I have a pretty small SolrCloud deployment with two servers plus a third zk
node, numShards=1. I don't implement separation here, but it's not really
needed. It currently places core directories right into solr.home, but I would
like to change that.
2) My main large Solr deployment doesn't use SolrCloud, and is not likely to
use SolrCloud in the foreseeable future. That is where I have things heavily
separated into cores, data, and config.
In a cloud/zk deployment, you get dataDir separation for free, because the core
config is elsewhere. This would also be the case with filesystem-based config
sets. We therefore might not need to worry too much about the separation idea
that I initially had, but I do think that it's important to have the cores go
into a subdirectory by default.
bq. would rather not start putting a bunch of stuff back into solr.xml if we
can help it
+1 from me on that. Anything that we can move out of that file we should -
basically make it so that only what's required at a global level to locate the
rest of the resources Solr needs, plus any server-level config options that
don't have an excellent all-purpose default. I think a 'coreDirectory' option
falls into both of those categories. In a ZK-controlled world, a lot of global
config options can be stored in ZK, but there are very good reasons to have a
different coreDirectory option on each server.
bq. I might like to rm -rf <solr_home> and put in a new release without
touching my data
What I do for this is completely separate solr.home and CWD (jetty.home). CWD
is /opt/solr4, solr.home is /index/solr4, and /index is a different filesystem.
There are jars for jetty and log4j in /opt/solr4/lib, and extra jars for solr,
lucene, and mysql in /index/solr4/lib.
> Finalize what we're going to do with solr.xml, auto-discovery, config sets.
> ---------------------------------------------------------------------------
>
> Key: SOLR-4662
> URL: https://issues.apache.org/jira/browse/SOLR-4662
> Project: Solr
> Issue Type: Improvement
> Affects Versions: 4.3, 5.0
> Reporter: Erick Erickson
> Assignee: Erick Erickson
> Priority: Blocker
>
> Spinoff from SOLR-4615, breaking it out here so we can address the changes in
> pieces.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
