-
Notifications
You must be signed in to change notification settings - Fork 651
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
Fact finding: Registry & client support for Image Manifest type artifacts #1025
Comments
So from what I've gathered so far a config blob is always needed in practice and if you have no binary blob to store (annotation only artifact) then a small blob, empty layers array or missing layers field all seem equivalent. As the spec is written now, I think most would say that allowing layers to be empty or absent breaks compatibility because one reading of the Image Manifest spec says that layer 0 is mandatory. In practice nobody that I tested has implemented it that way. So what shall we prescribe as the way to write an Image Manifest for an annotations only artifact? This is something I think should be clarified regardless of whether the Artifact Manifest is dropped or not. |
this is the confusion with the current spec wording: it was thought to say "the layer at index 0 is intended to be the base layer", and not that it must exist. |
I want to hear more opinions but I'd be open to making layers optional based on this. Again, I don't have a vote. |
FWIW, Docker Hub did add support for It does support both empty layers and no layers without a
The Docker Engine/CLI also has no problem with either image: $ docker pull tianon/scratch:oci
oci: Pulling from tianon/scratch
Digest: sha256:3d455195f1141b05cb8cc6deb07ea96b617e5436c7a259d9f3e7b1985f4d3f51
Status: Downloaded newer image for tianon/scratch:oci
docker.io/tianon/scratch:oci
$ docker pull tianon/scratch:nolayers
nolayers: Pulling from tianon/scratch
Digest: sha256:aad957e043852ec4cd630cabb56da94c024a0bb3a72bd4d530a13b8f6b752ca7
Status: Downloaded newer image for tianon/scratch:nolayers
docker.io/tianon/scratch:nolayers |
Can you point us at public versions of these images so we can reuse your test cases? |
Yes, references added above. |
|
Anyone have an active Artifactory config to check their support? |
I believe we ignored the option to have a single layer with a 0 size blob because of a registry support. Can we add that scenario to the list of tests? I want to be sure it's an issue with multiple registries and not just a one-off. |
Yes, added.
Added, I don't think this is a great option for two reasons:
|
As of this afternoon Quay.io are allowing any config media type, chart updated. Thanks siblings, I guess.. |
Never underestimate the power of a ❌ in a feature table to motivate change ;) |
|
Can I suggest we rename the heading Artifact in favor of Arbitrary config mediaType or something? The term "artifact" is very overloaded, and I think it could be misconstrued to mean "support for the v1.1-RC artifact manifest", which is out of scope of this fact finding mission. |
Just curious, how many customers are actually pushing OCI images to registries? |
Transliterated from: opencontainers/image-spec#1025 Signed-off-by: Ramkumar Chinchani <rchincha@cisco.com>
I did some testing on Harbor:
|
GCR and AR both appear to work with both zero layer and scratch layer. |
This thread is just awesome. It helped in driving change building clarity. Kudos to @brackendawson. |
Ref: opencontainers#1025 Signed-off-by: Vincent Batts <vbatts@hashbangbash.com>
Ref: opencontainers#1025 Signed-off-by: Vincent Batts <vbatts@hashbangbash.com>
Ref: opencontainers#1025 Signed-off-by: Vincent Batts <vbatts@hashbangbash.com>
Ref: opencontainers#1025 Signed-off-by: Vincent Batts <vbatts@hashbangbash.com>
Ref: opencontainers#1025 Through the conversations between artifact manifest and standardizing the misuse of the image-manifest one of the topics was around when there is _not_ a `config` needed for the `layers`/blobs. Since the `config` is a REQUIRED field, it meant setting this to some valid value. This guidance intends to set a norm for a blob that need only be pushed to a registry a single time, and then save on round trips for all future SCRATCH configs, while also being most widely portability. to facilitate use by tools that import this reference code to identify this specific blob when working with an empty/scratch config blob and layer blob. This will utilize the same blob for both Signed-off-by: Vincent Batts <vbatts@hashbangbash.com>
As v1.1.0 has been released I think this has served its purpose. Thank you everyone for helping me push this cat gif to the various registries. |
To hopefully help with #999 and #1015 I've tested various flavors of Image Manifest with various registries and client software. Please to chip in if you can try other registries & clients. And definitely let me know if the working group has documented something similar.
NB: The ✅ and ❌ do not indicate conformance, only of what we could do now would work in existing implementations.
Registries
Test manifest PUT and GET
* Docker Hub responds with "not found" to any OCI Image Manifest with a subject, even if the subject exists in the same repository. Subjects have been temporarily disabled.
Clients
Test pull and push
* Runtimes unpacking artifacts are almost certain to fail.
† If performed with a compatible config blob.
Manifests
The subject in these images is:
dev.icr.io/oci-artifacts/test:image
Arbitrary Config mediaType
dev.icr.io/oci-artifacts/test:artifact
No config
I can't upload this anywhere, but it references the same blobs as the one above.
Empty Layers
dev.icr.io/oci-artifacts/test:artifact-empty-layers
No Layers
dev.icr.io/oci-artifacts/test:artifact-no-layers
No Subject
dev.icr.io/oci-artifacts/test:artifact-no-subject
Zero Layer
alandaws/oci-artifacts:artifact-0-layer
(Subject is missing because Docker Hub).Scratch Layer
dev.icr.io/oci-artifacts/test:artifact-scratch-layer
The text was updated successfully, but these errors were encountered: