[ 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: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org