[
https://issues.apache.org/jira/browse/SOLR-15089?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17286747#comment-17286747
]
Tomas Eduardo Fernandez Lobbe commented on SOLR-15089:
------------------------------------------------------
{quote}But on the other hand I thought there was a certain amount of consensus
about net-new optional modules being created as plugins (and not contribs).
{quote}
I don't think there is a consensus for that? Some contribs were removed from
the code recently but I don't think that means no-more-contribs, I believe each
deserves it's own discussion, like the one we are having here. The closer there
is about this discussion in [the thread you
referenced|http://mail-archives.apache.org/mod_mbox/lucene-dev/202101.mbox/%3Calpine.DEB.2.21.2101141026530.13436%40slate%3E],
and people isn't in favor of moving "first party plugins" out of Solr repo
{quote}I don't want to go against consensus just out of convenience.
{quote}
contribs are convenient, for you, for users, for other devs, which make them a
good option IMO. Again, I think there is specific discussion to be had about
each one of them (new and old), we certainly don't want to allow code dumps
that fall unsupported and largely unused.
{quote}# I don't want bloat in the main repository with code that is clearly
optional to the search engine. solr-sandbox or solr-extras is better, IMHO.
{quote}
I understand Ishan, but that is exactly the discussion going on in the dev list
thread linked above. Most people agree that these first party
plugins/modules/contribs are better off with the Solr code, for various reasons
stated there.
{quote}# I don't want to be blocked on committing something to the main
repository, just because it breaks tests in s3mock, S3 support etc.
{quote}
I know that it may be annoying for a feature you don't want/use/need. I see
failures for features I don't use all the time, but that's exactly what
supporting a feature means. We want to know in advance if a change in Solr is
breaking our officially supported plugins, and we don't want to release a Solr
version that inadvertently breaks things we support. I want our testing to
prevent it.
{quote}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.
{quote}
This is the discussion going on
[here|http://mail-archives.apache.org/mod_mbox/lucene-dev/202101.mbox/%3Calpine.DEB.2.21.2101141026530.13436%40slate%3E]
right now. Docker already has a "slim" and a "fat" distribution, we can
certainly do that with Solr tars too if we want (I do believe we aren't there
yet, see my comment here). But again, I don't think we should block this work
until that decision is made. This particular feature has been requested
multiple times, different users have had to built their own, it's obviously
something people want and need, lets have 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
