[
https://issues.apache.org/jira/browse/SOLR-11508?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16280584#comment-16280584
]
Shawn Heisey commented on SOLR-11508:
-------------------------------------
bq. What benefit exactly would a "rename" of solr.data.home to solr.index.home
give?
The idea would be to clear up confusion. Based on how this issue started and
progressed, it seems that there's some confusion about what "data" means. The
initial expectation seems to have been that it would cover ALL of Solr's data,
including the conf directory, but in fact it only deals with the *index* data,
so solr.index.home seems like a better name for the property.
That confusion is also the reason that I mentioned the possibility of replacing
solr.solr.home with solr.data.home. Although the idea passes a sniff test, it
might cause confusion of a different kind for veterans, so it wouldn't be my
first preference.
Currently we have three things that can be configured, in chronological order:
solr.solr.home, coreRootDirectory, and solr.data.home. All of these have uses,
but I think the end result is particularly confusing for novices.
The reason I think we should kill coreRootDirectory: When I take a step back
and think about everything, I find little value in separating what's in the
solr home (solr.xml and configsets) from the rest of the configuration data.
I do find value in separating the config from the index data. That makes it a
lot easier to keep configurations in source control, and if you find yourself
in a place where you want to delete all index data but leave all the cores
intact, it's REALLY easy.
If I think about what the best option would be if we could start over, I come
up with the notion of having two configurations -- one for everything that's
not read-only (the solr home), and one for index data (currently
solr.data.home).
Accommodating an empty data volume for the solr home location is the last
wrinkle, and is solved by not *requiring* solr.xml. SolrCloud can already
handle an empty solr home, standalone should too.
> Make coreRootDirectory configurable via an environment variable
> (SOLR_CORE_HOME)
> --------------------------------------------------------------------------------
>
> Key: SOLR-11508
> URL: https://issues.apache.org/jira/browse/SOLR-11508
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
> Reporter: Marc Morissette
>
> (Heavily edited)
> Since Solr 7, it is possible to store Solr cores in separate disk locations
> using solr.data.home (see SOLR-6671). This is very useful when running Solr
> in Docker where data must be stored in a directory which is independent from
> the rest of the container.
> While this works well in standalone mode, it doesn't in Cloud mode as the
> core.properties automatically created by Solr are still stored in
> coreRootDirectory and cores created that way disappear when the Solr Docker
> container is redeployed.
> The solution is to configure coreRootDirectory to an empty directory that can
> be mounted outside the Docker container.
> The incoming patch makes this easier to do by allowing coreRootDirectory to
> be configured via a solr.core.home system property and SOLR_CORE_HOME
> environment variable.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
