[
https://issues.apache.org/jira/browse/SOLR-13035?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16706497#comment-16706497
]
Jan Høydahl commented on SOLR-13035:
------------------------------------
It is true that the primary use case for solr.data.home is for master/slave
where you want to keep config r/o on one partition and mount a large data drive
for the index. Then to push new config you just overwrite SOLR_HOME, which then
has no data in it.
Note that with Cloud you can first {{bin/solr zk cp solr.xml zk:/solr.xml}} and
then Solr will not complain if it does not find a local copy. But I also think
that we should just let Solr use a built-in default if it is not found instead
of failing. I think the argument was that if someone configured a SOLR_HOME
with a typo then it is a good thing to fail due to non-existing solr.xml, but
I'd like to trade that typo safety for usability/convenience. Perhaps with the
introduction of a new {{-DrequireSolrXml=true}} flag.
> Utilize solr.data.home / solrDataHome in solr.xml to set all writable files
> in single directory
> -----------------------------------------------------------------------------------------------
>
> Key: SOLR-13035
> URL: https://issues.apache.org/jira/browse/SOLR-13035
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Reporter: Amrit Sarkar
> Priority: Major
> Attachments: SOLR-13035.patch
>
>
> {{solr.data.home}} system property or {{solrDataHome}} in _solr.xml_ is
> already available as per SOLR-6671.
> The writable content in Solr are index files, core properties, and ZK data if
> embedded zookeeper is also started in SolrCloud mode. It would be great if
> all writable content can come under the same directory.
> It can then also solve official docker Solr image issues:
> https://github.com/docker-solr/docker-solr/issues/74
> https://github.com/docker-solr/docker-solr/issues/133
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
