[
https://issues.apache.org/jira/browse/SOLR-15089?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17286737#comment-17286737
]
Shawn Heisey commented on SOLR-15089:
-------------------------------------
I've had a lot of thoughts about these questions. More on the release side
than the code side.
I don't have strong thoughts about whether these ancillary components should be
contrib or not. We do need to decide that, but it's independent from concerns
about how we release the artifacts.
I would like to see a situation where we have a "main" solr download that is a
third of the current download size, or smaller if possible. That download
would only include core functionality, no bells or whistles. On the code side,
there should be a main repository that builds the main download. We would need
to decide whether we want individual repositories for other components, or one
big "plugins" repository. The same decision would need to be made for the
release side – one big plugins download, or a bunch of small ones. I can see
advantages and disadvantages to either approach.
Not too long ago, I noticed that the download for ES, our biggest competitor,
was under 30 MB, compared to 150MB for Solr. I just downloaded the latest ES
version, and it has ballooned to 300MB. I guess they now prefer the same
"kitchen sink" philosophy that we have always used ... and they have REALLY
embraced 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
> 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
