[
https://issues.apache.org/jira/browse/SOLR-15089?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17283690#comment-17283690
]
Jason Gerlowski edited comment on SOLR-15089 at 2/12/21, 1:35 PM:
------------------------------------------------------------------
bq. I would be happy to look into cleaning it up and submitting it for
consideration if you haven't started yet
Hey, that's great news Andy! I'm in a similar situation - I have code from my
employer (written largely by Shalin and Dat who I used to work with), but it
also needs some recontextualization/cleanup work before it's ready to share
here.
FWIW, my employer's implementation is well-tested but I don't think it's seen
much production traffic. So maybe your Salesforce implementation is a better
base to start from, since it sounds like it's seen a good bit of production
usage? If you're able to get things cleaned up for contribution, let's work
from what you have, and we can use my copy as a fallback or a sanity-check as
necessary.
(Ishan raised some good questions about where this code should ultimately live,
but if it makes it easier for you to share code we can handle that last. Feel
free to put your S3Repository code where-ever is easiest for the moment, and we
can relocate it as necessary at the end.)
bq. I would strongly prefer for this to stay outside of solr-core, preferably
in solr-extras repo (when that's created).
My primary goal for this is that it lives as ASF code _somewhere_. So I'm not
against solr-extras as a home, if the community has decided on that approach
for handling future contrib-y modules.
But does that consensus exist right now? The last email thread about it [ends
ambiguously|http://mail-archives.apache.org/mod_mbox/lucene-dev/202101.mbox/%3Calpine.DEB.2.21.2101141026530.13436%40slate%3E],
with Hoss asking some questions (that I seconded) about what benefits
{{solr-extras}} really provides over a single-repo approach.
>From that I was under the impression that {{solr-extras}} might happen, but
>was still very much up in the air. But I might've missed some mail on it?
was (Author: gerlowskija):
bq. I would be happy to look into cleaning it up and submitting it for
consideration if you haven't started yet
Hey, that's great news Andy! I'm in a similar situation - I have code from my
employer (written largely by Shalin and Dat who I used to work with), but it
also needs some recontextualization/cleanup work before it's ready to share
here.
FWIW, my employer's implementation is well-tested but I don't think it's seen
much production traffic. So maybe your Salesforce implementation is a better
base to start from, since it sounds like it's seen a good bit of production
usage? If you're able to get things cleaned up for contribution, let's work
from what you have, and we can use my copy as a fallback or a sanity-check as
necessary.
(Ishan raised some good questions about where this code should ultimately live,
but if it makes it easier for you to share code we can handle that at the end.
Feel free to put your S3Repository code where-ever is easiest for the moment.)
bq. I would strongly prefer for this to stay outside of solr-core, preferably
in solr-extras repo (when that's created).
My primary goal for this is that it lives as ASF code _somewhere_. So I'm not
against solr-extras as a home, if the community has decided on that approach
for handling future contrib-y modules.
But does that consensus exist right now? The last email thread about it [ends
ambiguously|http://mail-archives.apache.org/mod_mbox/lucene-dev/202101.mbox/%3Calpine.DEB.2.21.2101141026530.13436%40slate%3E],
with Hoss asking some questions (that I seconded) about what benefits
{{solr-extras}} really provides over a single-repo approach.
>From that I was under the impression that {{solr-extras}} might happen, but
>was still very much up in the air. But I might've missed some mail on it?
> Allow backup/restoration to Amazon's S3 blobstore
> --------------------------------------------------
>
> Key: SOLR-15089
> URL: https://issues.apache.org/jira/browse/SOLR-15089
> Project: Solr
> Issue Type: Sub-task
> Security Level: Public(Default Security Level. Issues are Public)
> Reporter: Jason Gerlowski
> Priority: Major
>
> Solr's BackupRepository interface provides an abstraction around the physical
> location/format that backups are stored in. This allows plugin writers to
> create "repositories" for a variety of storage mediums. It'd be nice if Solr
> offered more mediums out of the box though, such as some of the "blobstore"
> offerings provided by various cloud providers.
> This ticket proposes that a "BackupRepository" implementation for Amazon's
> popular 'S3' blobstore, so that Solr users can use it for backups without
> needing to write their own code.
> Amazon offers a s3 Java client with acceptable licensing, and the required
> code is relatively simple. The biggest challenge in supporting this will
> likely be procedural - integration testing requires S3 access and S3 access
> costs money. We can check with INFRA to see if there is any way to get cloud
> credits for an integration test to run in nightly Jenkins runs on the ASF
> Jenkins server. Alternatively we can try to stub out the blobstore in some
> reliable way.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
