[
https://issues.apache.org/jira/browse/SOLR-9242?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15356701#comment-15356701
]
Varun Thacker commented on SOLR-9242:
-------------------------------------
Hi Hrishikesh,
bq. we can restrict the users to configure only a single repository at-a-time.
This will avoid the problem mentioned above and they can use the current
property.
Personally I don't like the idea of limiting our users to one repo in all of
the 6.x line.
Let's say we follow this order:
1. If "location" param was provided as a query param use that
2. Else if the "repository" in the solr.xml has a "location" param use that.
3. If the "repository" specified doesn't specify a "location" param then see if
it's specified via the cluster property API . The code will throw an error if
the location was bogus or was with not for this repo. It has to fail as the
repository will fail to read / write to that location.
I thought about the "repoName:/path" syntax idea that you proposed . Seems to
me that we want to do all of this because solr.xml doesn't have an API to
update it . We have to hand edit the file and upload to ZK at the very least.
I think let's not complicate it any further? Keep the location cluster prop for
now the way it is and support it.
We can work towards adding API support to solr.xml and then get rid the
"location" cluster prop or the entire cluster prop API in the future.
> Collection level backup/restore should provide a param for specifying the
> repository implementation it should use
> -----------------------------------------------------------------------------------------------------------------
>
> Key: SOLR-9242
> URL: https://issues.apache.org/jira/browse/SOLR-9242
> Project: Solr
> Issue Type: Improvement
> Reporter: Hrishikesh Gadre
> Assignee: Varun Thacker
> Attachments: SOLR-9242.patch
>
>
> SOLR-7374 provides BackupRepository interface to enable storing Solr index
> data to a configured file-system (e.g. HDFS, local file-system etc.). This
> JIRA is to track the work required to extend this functionality at the
> collection level.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
