Ok, that’s the one I was looking for, it’s not documented in the backup chapter of ref-guide :(
Jan Høydahl > 23. des. 2020 kl. 17:10 skrev Jason Gerlowski <[email protected]>: > > >> >> We have a path alias to the old API ... but we don’t have a true v2 API spec >> for it, do we? > > Tbh I'm not yet familiar enough with the v2 APIs to understand the > distinction you're making. (Do you have a pointer to something that'd > fill me in?) > > To zoom in on "backup" as an example, the v2 API I'm referring to > looks like: /v2/collections" -d '{ "backup-collection": > {"collection": "books", "name": "asdf3", "location": "/tmp/foo"}}'. > And it's included in the v2 "introspect" documentation returned by > this API: /v2/collections/_introspect?command=backup-collection". To > me that looked like a v2 API, but maybe path-aliases are also covered > in the introspect docs. > > Jason > >> On Wed, Dec 23, 2020 at 10:29 AM Jan Høydahl <[email protected]> wrote: >> >> Actually, don’t think we do have a v2 Backup/Restore API. We have a path >> alias to the old API which takes GET ...&action=backup... but we don’t have >> a true v2 API spec for it, do we? Where is that documented? >> >> Jan Høydahl >> >>>> 22. des. 2020 kl. 18:04 skrev Jason Gerlowski <[email protected]>: >>> >>> Hey guys, >>> >>> Following up to make sure I understand the specifics you're >>> suggesting. You're proposing that: >>> >>> 1. The brand new backup-related APIs (list-backups and delete-backup) >>> be added in v2-form only. >>> 2. Tweaks to existing backup-related APIs (create-backup, restore) be >>> made in V2-form only. >>> 3. All existing v1 backup-related APIs be deprecated and left >>> unchanged. Incremental backups will not be possible using the v1 API. >>> >>> I'm not against going this route if there's consensus around it. But >>> I'm not 100% clear on how it means we don't need to worry about >>> backcompat. Backup and Restore currently exist as both a v1 and a v2 >>> API - I understand how leaving the v1 APIs untouched (other than >>> deprecation) frees us of some backcompat concerns there, but we would >>> still need to make tweaks to the v2 backup/restore APIs and would have >>> to tread just as carefully there in terms of backcompat, afaict. >>> Unless Solr's backcompatibility guarantees only cover the v1 API and >>> leave v2 changes to be made freely? I looked around to see if the v2 >>> APIs had any sort of "experimental" designation, but couldn't find >>> that clearly stated anywhere. Am I missing something? >>> >>> Best, >>> >>> Jason >>> >>>> On Tue, Dec 22, 2020 at 2:49 AM Noble Paul <[email protected]> wrote: >>>> >>>>> , and implement the new imporved version as a V2-api only, and then >>>>> deprecate the v1 API? >>>> >>>> >>>> V2 only please >>>> >>>>> On Tue, Dec 22, 2020 at 1:34 AM Jason Gerlowski <[email protected]> >>>>> wrote: >>>>> >>>>> Hey Jan, thanks for the review. >>>>> >>>>> I hadn't thought about the V2 API in connection to this work. You're >>>>> right though I think - the SIP proposes net-new APIs, so it should add >>>>> V2 equivalents at the very least. I'll draft tentative details for >>>>> these APIs on the SIP and we can refine things from there. >>>>> >>>>> I'm more up in the air on your specific suggestion to restrict the SIP >>>>> changes to these v2 APIs. It is an elegant approach to the >>>>> backcompat, and it provides a carrot for v2 adoption - both of which I >>>>> like. But it would let users create snapshot-based backups (and keep >>>>> us maintaining that code) longer than there's any strict need to. And >>>>> users are left on the less-efficient format by default. (By contrast, >>>>> the current SIP has snapshot-backup creation being replaced by >>>>> incremental-backup creation as soon as the latter is available.). Did >>>>> you have a particular lifespan in mind for snapshot-based creation if >>>>> we go with this approach? >>>>> >>>>> Jason >>>>> >>>>> On Thu, Dec 17, 2020 at 3:54 PM Jan Høydahl <[email protected]> wrote: >>>>>> >>>>>> Much needed! Thanks for initiating this Jason! >>>>>> >>>>>> As we want to move away from v1 APIs where a HTTP GET is used for >>>>>> creation and deletion, would it be an idea to leave the old >>>>>> backup/resotre APIs as-is, and implement the new imporved version as a >>>>>> V2-api only, and then deprecate the v1 API? Then we don't need to worry >>>>>> about back-compat, and we get a head-start on converting the COLLECTION >>>>>> API to v2 style. >>>>>> >>>>>> Jan >>>>>> >>>>>>> 15. des. 2020 kl. 15:48 skrev Jason Gerlowski <[email protected]>: >>>>>>> >>>>>>> Hey all, >>>>>>> >>>>>>> This morning I published SIP-12, which proposes an overhaul of Solr's >>>>>>> backup and restore functionality. While the "headline" improvement in >>>>>>> this SIP is a change to do backups incrementally, it bundles in a >>>>>>> number of other improvements as well, including the addition of >>>>>>> corruption checks, APIs to list and delete backups, and stronger >>>>>>> integration points with popular object storage APIs. >>>>>>> >>>>>>> The SIP can be found here: >>>>>>> https://cwiki.apache.org/confluence/display/SOLR/SIP-12%3A+Incremental+Backup+and+Restore >>>>>>> >>>>>>> Please read the SIP description and come back here for discussion. As >>>>>>> the discussion progresses we will update the SIP page with any >>>>>>> outcomes and eventually move things to a VOTE. >>>>>>> >>>>>>> Looking forward to hearing your feedback. >>>>>>> >>>>>>> Best, >>>>>>> >>>>>>> Jason >>>>>>> >>>>>>> --------------------------------------------------------------------- >>>>>>> To unsubscribe, e-mail: [email protected] >>>>>>> For additional commands, e-mail: [email protected] >>>>>>> >>>>>> >>>>>> >>>>>> --------------------------------------------------------------------- >>>>>> To unsubscribe, e-mail: [email protected] >>>>>> For additional commands, e-mail: [email protected] >>>>>> >>>>> >>>>> --------------------------------------------------------------------- >>>>> To unsubscribe, e-mail: [email protected] >>>>> For additional commands, e-mail: [email protected] >>>>> >>>> >>>> >>>> -- >>>> ----------------------------------------------------- >>>> Noble Paul >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: [email protected] >>>> For additional commands, e-mail: [email protected] >>>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: [email protected] >>> For additional commands, e-mail: [email protected] >>> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
