-
Notifications
You must be signed in to change notification settings - Fork 97
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Designing ORAS #39
Labels
help wanted
Extra attention is needed
Comments
I just noticed that I can put this doc into the Wiki page of the |
Closed
I wanted to make sure were have an API spec for this - Do we need to remove ProviderWrapper types since they will have to be non-breaking if we release them is my understanding /cc @deitch
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Introduction
ORAS is a tool for working with OCI artifacts, especially ones in the OCI registries. It provides user-friendly interfaces to push and pull artifacts to / from registries as well as options for advanced scenarios.
Unified Experience
The objective of ORAS is simple as transferring artifacts from one place to another.
In the conventional client-server model, the operation of downloading artifacts from the remote registries is referred to as pull, and the operation of uploading artifacts from the remote registry is referred to as push.
This model can be generalized by abstracting the client and the server as targets so that pull and push can be viewed as copying from one target to another (see #8). For instances,
Targets
Generally, a target is a content-addressable storage (CAS) with tags. All blobs in a CAS are addressed by their descriptors.
To retrieve a blob,
To store a blob,
It is worth noting that a target is not equal to a registry.
Graphs
Besides plain blobs, it is natural to store directed acyclic graphs (DAGs) in a CAS. Precisely, all blobs are leaf nodes and most manifests are non-leaf nodes.
An artifact is a rooted DAG where its root node is an OCI manifest. Additionally, artifacts can be grouped by an OCI index, which is also a rooted DAG.
Given a node of a DAG in a CAS, it is efficient to find out all its children. Since CASs are usually not enumerable or indexed, it is not possible to find the parent nodes of an arbitrary node. Nevertheless, some CASs choose to implement or partially implement the functionality of parent node finding. For instances, registries with Manifest Referrers API support are CASs with partially implementation where parent node finding is only available for manifest nodes.
Extended Copy
With the concepts above, we can formally define that
It is worth noting that extended copy is possible only if the source CAS supports parent node finding. Based on the scenarios, extended copy can have many options such as opting to copy a sub-DAG rooted by a certain node and all its parent nodes of a certain depth with / without their children.
Optionally, node filters or even node modifiers can be attached to a copy process for advanced scenarios.
Related issues:
Hint: A polytree is a DAG.
Challenges
We have lots of challenges in developing and maintaining ORAS:
oras-go
library should have as less dependencies as possible.containerd
as we just need a little bit of that project.containerd
related implementation in theexamples
folder.The text was updated successfully, but these errors were encountered: