Possible extension to API needed for oci download and upload
Opened this issue · 3 comments
Please see sylabs/scs-library-client#150 and sylabs/scs-library-client#151 regarding the possible need to add to the library-api standard.
Hello all.
The two referenced PRs in the Sylabs scs-library-client don't really affect the library standard API per se. These changes are related to an offload of transfers directly to an OCI registry, in the case that a library service is backed by an OCI registry as the image store, implemented in a specific manner.
This currently applies only to a forthcoming implementation within Singularity Enterprise / SCS (cloud.sylabs.io). Both sides of Sylab's implementations, client and server, fall back to the open standard API if the offload isn't implemented.
Adam is off at the moment, but as he is the person from Sylabs on the list of maintainers for this library-api project, I'll ask him to engage on this topic, if necessary, when he returns after the holidays.
Yeah - superficially this sounds like just implementing something like ORAS.
Yeah - superficially this sounds like just implementing something like ORAS.
Yeah, kinda. If you considered it outside of the context of Singularity Enterprise / cloud.sylabs.io then you could look at it a bit like there being a library:// protocol and some auth in front of an ORAS-like backend.
Unless you are Sylabs, I'd suspect that you'd want to just switch to using oras:// directly for OCI storage, and otherwise stay on the library:// protocol as defined in the open API at present. But if there's more debate around that we can engage after the holidays, as above.
Cheers!