-
Notifications
You must be signed in to change notification settings - Fork 663
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
Using an image index to reference nested related artifacts #1217
Comments
Hi @arewm. I believe it's possible to have a nested index today with the current specs. What is the specific change you are looking for from the spec? Is it for a standard around querying annotations? |
I might have made a poor choice of terms. I assume that it is possible to have an image index point to another image index within the same namespace. What isn't possible possible is to point to an image within a further scoped namespace. What does work:Produce an image in a repository
Create an image index referring to that
Is wrapping this in an image index what is supposed to be supported by the spec?
What doesn't work but is proposed:Produce an image in a repository
Then trying to point to that from an image index in a "parent" namespace
Proposed change to the spec to add support for nested artifact namespacesIn the details above that don't work, quay returns an error because the registry couldn't find a manifest with the provided digest. If we add an additional optional property for the |
This issue also come from me, as a registry user, expecting that namespaces within a registry should roughly correspond to logically similar artifacts. When it comes to binary containers, for example (i.e. Artifacts stored in a registry have relationships to each other. For me, the relationships can be described with:
|
There's no concept of a cross-repository descriptor in OCI, every descriptor references content in the same repository. Trying to change that is likely to face a lot of resistance due to all the issues it creates. A few issues I can think of:
Right now, any cross repository logic is registry specific and requires client configuration. E.g. it is possible to push an artifact with a subject digest that does not exist in the current repository. However, registries are permitted to implement their own garbage collection process that would include that content, and clients would need to know how to find the subject digest from another repository and be configured with the repository name to perform the referrers API. Similarly, it's possible to push an Index that has descriptors that do not exist in the local repository (this is specifically desired for sparse copies that only include specific platforms used in an environment). However, most registries reject that as part of their validation, and many clients would break if they attempted to consume content and follow the path to a missing digest. To support your own use case, you would need a registry that doesn't validate the Index, and would need client tooling that knows how to find the content in different repositories. Overall, the easy answer is to put all of the content in the same repository, but realize that some registries may reject a nested Index even when the referenced content exists (I recall someone validating the media types listed in an OCI Index were limited to only an OCI Image). Also, clients need to be configured to know how to walk a nested Index to find their content. |
We have encountered some use cases where we would like to associate multiple related artifacts but which would still benefit from having their own namespace location.
ko
to produce multiple container images. While each of these image indexes can be pushed independently, we want to also associate them as being produced together by the single task. If we configure theko
build to push toquay.io/<username>/myrepo/ko-build/<image-name>
, the task could return a single resultquay.io/<username>/myrepo/ko-build
which would map to all image indexes. (side note: chains should also support recursive index images).quay.io/<username>/myrpmrepo
and the contained RPMs toquay.io/<username>/myrpmrepo/<rpm>
image manifests.Since an image index only has a reference to the digest for the referenced image index/manifest, it is not possible to map to reference any nested artifacts. Any client that is interested in supporting this functionality would need to add some form of client-specific encoding (i.e. via annotations) on the image index.
While some might be interested in having an image index refer to arbitrary pullspecs, I think that it is better to scope the references only to nested relationships as it is likely easier for registries to implement authorization models for these relationships. Being able to have a common authorization for all referenced artifacts would result in a better user experience.
The text was updated successfully, but these errors were encountered: