[
https://issues.apache.org/jira/browse/SOLR-15089?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17287128#comment-17287128
]
Jason Gerlowski commented on SOLR-15089:
----------------------------------------
bq. I don't think there is a consensus for that?
Ok, fair enough. I started to wonder the same thing when I couldn't find the
discussion I thought I remembered.
The concerns Ishan cited above arguing for a separate repo don't resonate with
me personally, and I agree with Tomas' responses to them.
But that makes me "anti-separate-repo" not "anti-plugin", and that's an
important distinction.
Assuming it lives in `lucene-solr`, there are good technical reasons to
consider plugin packaging: plugins can have their own release cadence, they
needn't be shipped by default, etc. There are good strategic reasons too.
We've told the community that plugins are a first class thing, and they're the
way to go in Solr development. It's been highlighted in upgrade notes,
presented on at conferences, there's a [website|https://solr.cool] of sorts,
etc. Telling users to do one thing while we continue to do another undercuts
that message in a big way. And it deprives users of concrete examples they
need to make their own non-trivial plugins.
That's not to say that this *must* be a plugin IMO. Just that in an ideal
world where the community has answers to SOLR-14688's questions, that's the way
I'd lean.
But at the same time, Tomas is right that there's a clear desire for this
feature and letting it miss the next release while we wait on answers would be
a mistake. So for now I will go with contrib-packaging on these object-store
tickets, and they can be reviewed in that form. But I'll leave the PRs
uncommitted until either there's answers on SOLR-14688 that I can adopt if
applicable, or 8.9 or 9.0 starts to get concrete.
> 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
> Reporter: Jason Gerlowski
> Assignee: 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
