[
https://issues.apache.org/jira/browse/SOLR-4662?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13619867#comment-13619867
]
Shawn Heisey commented on SOLR-4662:
------------------------------------
I too think that solr.xml should not store cores. Auto-discovery is a nice
thing, but it makes it more difficult to have a nice clean layout where the
core configs and data are contained within separate subdirectories. I suppose
that each autodiscovered core properties file could have a relative dataDir
that goes up one or two directories, just like my current setup, and that might
be good enough. I would also want to have something like a coreDirectory
parameter, which I would set to "cores" so that the main solr.solr.home
directory would be very clean.
One option is to have a cores.xml file for more complex layouts where the user
wants to specify everything. At first I thought about a cloud.xml file for
SolrCloud properties, but once you start down the path of multiple config
files, the explosion might never stop.
Here's what things look like inside solr.xml on my setup that's not well suited
for SolrCloud, and a snippet of the full directory structure. The full picture
is more complex than this, with relative symlinks in conf directories and
relative xinclude paths in solrconfig.xml, but this gives you the basic idea:
{noformat}
<core loadOnStartup="true" instanceDir="cores/inc_0/" transient="false"
name="inclive" dataDir="../../data/inc_0"/>
<core loadOnStartup="true" instanceDir="cores/inc_1/" transient="false"
name="incbuild" dataDir="../../data/inc_1"/>
├── cores
│ ├── inc_0
│ │ └── conf
│ ├── inc_1
│ │ └── conf
├── data
│ ├── inc_0
│ │ ├── index
│ │ └── tlog
│ ├── inc_1
│ │ ├── index
│ │ └── tlog
└── lib
{noformat}
I'm not sure there is a better location than solr.xml for zkHost, but I
definitely think it should be in a config file. **Requiring** -DzkHost on
startup is a bad idea - generic startup scripts become very difficult. Keeping
all of the config after that in zookeeper is an idea that is growing on me, as
long as the initial contact to zookeeper won't suffer from a low default client
timeout before zkClientTimeout can be read.
If you give Solr (or CloudSolrServer) only one of the hosts in your zookeeper
ensemble (perhaps localhost:port/chroot) will it automatically configure itself
with the entire ensemble? If not, is there a way to build this functionality
in?
The fact that Solr does not come equipped with instructions for a standalone
zookeeper process or a functioning standalone zookeeper is problematic in my
opinion. If I find some time, I can whip up a wiki page. I do wish zkcli.sh
was more self-contained. I can eventually come up with a wiki page for that
too.
> 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
