Discussion: ORAS to split go-libraries and ORAS binary, with a 3rd Ref Implementation

[SteveLasker]

The primary intent of ORAS is to enable new artifact authors to utilize existing OCI distribtuion-spec, w/OCI Artifact enabled registries for their new artifact type. Thus avoiding the requirement to build and maintain Yet Another Storage Solution (YASS).

As we've converged on adopting ORAS to OCI, questions surfaced for what is ORAS?

• Is it a reference implementation?
• Is it a set of libraries
  • If it's a set of libraries, to be donated to OCI, why does it pull in so many external libraries?

This mix is the result of ORAS being both a set of libraries and a generic test harness. The test harness, while extremely useful, has confused the intent of the initial project, and still doesn't provide a clean refernece implementation for the average developer to easily implement. There have been requests for additional language implementations of the ORAS capabilities, such as ORAS-python.

I'd propose the following:

1. The core ORAS repository is refactored to provide a set of go-libraries that enable artifact authors. This would simplify the desire to add OCI Artifact capabilities.
   • login, push, pull, delete*
   • an extension model, enabling additional auth-providers - Registry Auth Extensibility oras-project/oras#177
   • libraries supporting oci-manifest generation (Get digest before push oras-project/oras#161), based on a set of files
   • reconcile the local OCI store ([documentation request] Add doc about OCIStore oras-project/oras#160) with containerd as we'll likely need a means to represent objects to be pushed/pulled to a registry
   • support config push/pull apis: (oras pull to support pulling the manifest.config object oras-project/oras#131
     Open)
2. A new ORAS-client (binary) repo that provides an iteration/test harness for the various ORAS libraries. It provides generic functionality for the wide range of capabilities provided by the ORAS libraries. It is NOT intended to be cloned/forked directly.
   • ORAS mediaTypes should default to unknown oras-project/oras#115
   • oras pull shouldn't require --media-type or --allow-all oras-project/oras#130
   • implement the issues captured here: Simplify ORAS default experience oras-project/oras#178
3. A new regdoc reference implementation that has the most basic capabilities of login, push, pull, delete. It would not expose config as a user parameter, nor the embedded mediaTypes, just as helm, wasm, singularity expose their internal config or mediaType values.

Both regdoc and the ORAS-client would implement Notaryv2, demonstrating signing capabilities.

To support additional OCI Artifact schema types, regdoc may be enhanced to store collections, or we may need a more complex example. Whether ORAS becomes its own root org, or placed under http://github.com/opencontainers/ is a separate discussion, and only limited by the number of individual repos placed under a single org, as opposed to different orgs be managed by OCI.

Alternative Option

Should the ORAS go libraries that enable OCI Artifacts move into the OCI Artifacts repo? This would be similar to distribution-spec specs-go/ and image-spec specs-go/.

This would free up ORAS to be the ORAS client project, leaving regdoc as the reference implementation.

[jdolitsky]

I have no problem moving the libraries under opencontainers/artifacts

[shizhMSFT]

Yes, we should at least split the library and command line tool.

[gaocegege]

I am looking forward to this feature! We are using oras to build our OCI artifacts for ML Models: https://github.com/kleveross/ormb

We are using oras as a library here: https://github.com/kleveross/ormb/blob/master/pkg/oras/client.go#L32

The code is mostly copied from helm chart. I think if we could split oras reference implementation and golang libraries, it helps artifact authors like us to write the business logic easily.

[jdolitsky]

This is done:

• CLI: https://github.com/oras-project/oras
• Library: https://github.com/oras-project/oras-go

[vsoch]

I was following this issue intending to implement a python version - is this still desired? And if so, should I use the CLI link as reference?

[SteveLasker]

Hi Venessa,
Yes, all languages are welcomed. This was one of the reasons to move from deislabs to it’s own org, provide for more language specific repos.

[vsoch]

okey doke! I can probably start on this over the weekend. In case it matters for the future, I'm a "Vanessa." Thanks for the update!

[SteveLasker]

Thanks, and apologies for the misspelling.
If you'd like to create a repo under your own org and stage the python work, we can create the repo when you're ready. Or, if you'd like a oras-python repo to start from there, we can likely do that as well. Let us know what you'd prefer.

[vsoch]

I'm pretty indifferent - a repo transfer is just as much work on your end as creating one, so it's probably easiest for me to start on my user account and then transfer. I'll post an update here after some work this weekend!

[jdolitsky]

@vsoch - we actually have a placeholder for this: https://github.com/oras-project/oras-py

I've just added you to maintainers team, feel free to push to a branch there!

oras-go is currently undergoing a redesign of the API. I would love for the Python version to match that API, so users going between the two have a familiar library to work with. Would you mind reaching out in Slack/Email to discuss further?