[
https://issues.apache.org/jira/browse/SOLR-15737?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17617296#comment-17617296
]
Jason Gerlowski commented on SOLR-15737:
----------------------------------------
Hi [~duttsanjay] - Yes, I think each of the "core-admin" APIs I mentioned in my
initial comment could use its own ticket. If you were willing to file some
"subtask" JIRAs for those and/or start work on one of them, that'd be awesome.
Thanks!
{quote}that command for core back up does not feel right
{quote}
Ah, I think you're comparing two different APIs.
TL;DR - Solr, really confusingly, has 3 (holy cow!) different user-facing APIs
that perform some sort of backup. At least 2 of which actually don't have v2
equivalents. So I suspect you're probably looking at the wrong row of the
spreadsheet.
In my initial comment I was referring to the /admin/cores?action=BACKUPCORE
internal API, but it sounds like you stumbled across the "Replication Backup"
API in the spreadsheet. Both of those APIs are missing v2 coverage, and are
fair game to create a JIRA for and start on. (This extends to any APIs in that
spreadsheet whose "v2 Example (Current)" column is empty).
----
For the curious, here are Solr's user-facing backup-related APIs:
# "Collection Admin" Backups
** In my experience the "main" way that SolrCloud users take backups. Backups
up an entire "collection" (which may contain multiple cores). Support for
incremental backups; storing data in pluggable "BackupRepositories", etc.
** Tab 1, line 83 of the "[Solr v2 API Proposed
Changes|https://docs.google.com/spreadsheets/d/1HAoBBFPpSiT8mJmgNZKkZAPwfCfPvlc08m5jz3fQBpA/edit?usp=sharing]";
spreadsheet.
** Relies on the "core admin" BACKUPCORE API under the hood
(/admin/cores?action=BACKUPCORE), which has no v2 equivalent.
** {*}v1 API{*}: /admin/collections?action=BACKUP
** {*}v2 API{*}: POST /api/collections cmd=backup-collection
# "Snapshot" Backups
** Uses file system soft-links to create a "snapshot" of your index at a
particular time without copying files around, etc. So a very different approach
from other backups, which at the end of the day have to copy all your index
bits somewhere. Not sure what the main usecase for this is.
** Tab 1, line 91 of the "[Solr v2 API Proposed
Changes|https://docs.google.com/spreadsheets/d/1HAoBBFPpSiT8mJmgNZKkZAPwfCfPvlc08m5jz3fQBpA/edit?usp=sharing]";
spreadsheet.
** {*}v1 API{*}: /admin/collections?action=CREATESNAPSHOT
** {*}v2 API{*}: None
# "Replication" Backups
** Much like the "Collection Admin" backups, but doesn't support incremental
backups and only performs the backup for a single specified core (afaict). Does
make use of the "BackupRepository" abstraction though.
** Tab 5, line 22 of the "[Solr v2 API Proposed
Changes|https://docs.google.com/spreadsheets/d/1HAoBBFPpSiT8mJmgNZKkZAPwfCfPvlc08m5jz3fQBpA/edit?usp=sharing]";
spreadsheet.
** {*}v1 API{*}: /collName/replication?command=backup
** {*}v2 API{*}: None
IMO, Solr really really needs to merge some of these APIs to clear things up
for users (and to help with maintenance). But that's a job for another JIRA I
guess.
> Ensure all (desired) v1 APIs have v2 equivalent
> -----------------------------------------------
>
> Key: SOLR-15737
> URL: https://issues.apache.org/jira/browse/SOLR-15737
> Project: Solr
> Issue Type: Improvement
> Components: v2 API
> Reporter: Jason Gerlowski
> Priority: Major
> Labels: V2, newdev
>
> Nothing in Solr's build system enforced consistency across v1<->v2, so as a
> result today, many v1 APIs (or API sub-commands) have no v2 counterpart. In
> some rare cases this was intentional (e.g.
> \{{/solr/admin/collections?action=MIGRATESTATEFORMAT}} ), but in most cases
> it's the result of unintentional omission.
> This ticket aims to remedying this, by finding v1 APIs without a v2
> counterpart and adding them where desired.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
