You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@lucene.apache.org by "Shawn Heisey (JIRA)" <ji...@apache.org> on 2017/11/30 21:26:00 UTC

[jira] [Comment Edited] (SOLR-11508) core.properties should be stored $solr.data.home/$core.name

    [ https://issues.apache.org/jira/browse/SOLR-11508?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16273380#comment-16273380 ] 

Shawn Heisey edited comment on SOLR-11508 at 11/30/17 9:25 PM:
---------------------------------------------------------------

bq. Wouldn't this possibly break existing Solr installations?

I hadn't thought of that, but I think you may be right.  If somebody has defined solr.data.home in a 7.1 install, then they upgrade Solr to a new version with this patch applied, I am pretty sure that the new version of Solr will not load any of the existing cores on its first startup, because there will not be any core.properties files for it to find.

This sounds like a really bad idea.

[~marc.morissette], if you're specifying a different directory for data than you are for config, why do you want to have the core.properties file in the data directory?  Do you also want the conf directory to be moved?  if not, then this makes no sense at all to me.  If you DO want the conf directory to move, then you simply need to set solr.solr.home and NOT solr.data.home, and everything moves.

In my opinion, whoever set up the docker image for Solr did it wrong.  They should have used our service installer script, which would have put the program into /opt/solr and everything else in /var/solr, with solr.solr.home set to /var/solr/data.  Instead, the docker image has the solr home in /opt/solr/server/solr ... similar to what happens when somebody manually starts solr instead of starting an installed service.



was (Author: elyograg):
bq. Wouldn't this possibly break existing Solr installations?

I hadn't thought of that, but I think you may be right.  If somebody has defined solr.data.home in a 7.1 install, then they upgrade Solr to a new version with this patch applied, I am pretty sure that the new version of Solr will not load any of the existing cores on its first startup, because there will not be any core.properties files for it to find.

This sounds like a really bad idea.

If you're specifying a different directory for data than you are for config, why do you want to have the core.properties file in the data directory?  Do you also want the conf directory to be moved?  if not, then this makes no sense at all to me.  If you DO want the conf directory to move, then you simply need to set solr.solr.home and NOT solr.data.home, and everything moves.

In my opinion, whoever set up the docker image for Solr did it wrong.  They should have used our service installer script, which would have put the program into /opt/solr and everything else in /var/solr, with solr.solr.home set to /var/solr/data.  Instead, the docker image has the solr home in /opt/solr/server/solr ... similar to what happens when somebody manually starts solr instead of starting an installed service.


> core.properties should be stored $solr.data.home/$core.name
> -----------------------------------------------------------
>
>                 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
>
> 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 where running Solr in Docker where data must be stored in a directory which is independent from the rest of the container.
> Unfortunately, while core data is stored in {{$\{solr.data.home}/$\{core.name}/index/...}}, core.properties is stored in {{$\{solr.solr.home}/$\{core.name}/core.properties}}.
> Reading SOLR-6671 comments, I think this was the expected behaviour but I don't think it is the correct one.
> In addition to being inelegant and counterintuitive, this has the drawback of stripping a core of its metadata and breaking core discovery when a Solr installation is redeployed, whether in Docker or not.
> core.properties is mostly metadata and although it contains some configuration, this configuration is specific to the core it accompanies. I believe it should be stored in solr.data.home, with the rest of the data it describes.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org