[
https://issues.apache.org/jira/browse/SOLR-11508?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16278034#comment-16278034
]
Shawn Heisey commented on SOLR-11508:
-------------------------------------
If Solr no longer requires solr.xml to start, then the solr home can be
completely empty on startup, fulfilling the requirements mentioned for the data
volume on Docker.
If you're in standalone mode and you create a core with the commandline, then
the commandline script will copy a config to ${instancedDir}/conf (where the
instanceDir is inside the solr home), and when Solr is informed about the new
core with the CoreAdmin API, part of the core startup will create
${instanceDir}/data, and under that directory, Lucene will create the index
directory.
bq. but it would condemn cloud mode users to choose between sticking to the
default settings or mixing their configuration and data.
In cloud mode, Solr doesn't mix config and data. The config is not on disk at
all. It's in zookeeper. Even solr.xml can be in zookeeper when running in
cloud mode. Which means that cloud mode can ALREADY work with no solr.xml file
in the solr home, just like I am describing.
bq. It's either that or we would need to externalize every configuration
parameter available in solr.xml
I agree that it would be important to make sure that a certain critical subset
of solr.xml configuration parameters must be configurable with system
properties, which should definitely include the various home directories, but I
don't think that *everything* needs to be configurable that way. Even though
solr.xml would not be REQUIRED to start Solr, you'd still be able to create
that file and have Solr honor its settings.
So to reiterate my modified proposal, for the master branch only:
{quote}
Eliminate coreRootDirectory entirely.
Make sure there are only two "home" properties. One of them should be
solr.index.home, and the other will either be solr.solr.home or solr.data.home.
The latter makes a lot of sense, but the former has historical value and will
support older configs better. If both solr.solr.home and solr.data.home are
set in an upgraded configuration, Solr should log an error and refuse to start.
Solr should be able to start up without a solr.xml file, but if one is found
(either in zookeeper or the solr home) then it will be honored.
{quote}
We could backport these ideas to 7.x, but the "new" way of configuring things
would have to be explicitly enabled, probably with a system property, and the
current way of configuring things would need to remain supported for all of 7.x.
> 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
