search

opencontainers / distribution-spec

OCI Distribution Specification
https://opencontainers.org
Apache License 2.0
792 stars 199 forks source link

Use artifactType from image manifest #395

Closed sudo-bmitch closed 1 year ago

sudo-bmitch commented 1 year ago

This updates the guidance to use the artifactType value first, and fall back to the config.mediaType when determining the artifactType to set in the referrers response. This should be merged after https://github.com/opencontainers/image-spec/pull/1043 is approved.

rchincha commented 1 year ago

lgtm

sudo-bmitch commented 1 year ago

@andaaron

From the perspective of the consumer of the API does it matter if the match is made on the config descriptor mediaType or the artifactType? I guess if someone codes a client which handles a limited types of artifacts it doesn't matter, because he can handle each case individually by verifying the artifactType value, but I think there should be a way to distinguish the source of the artifact type value in the reply itself to handle more generic cases.

I'm looking at it from a progressive upgrade with backwards compatibility. An existing artifact that has a dedicated config blob and media type can continue using that to avoid impacting existing clients. A new artifact that needs a config blob, but also wants a specific artifactType can do that, and find itself using that artifactType. And a new artifact without a config blob is required to specify an artifactType because "scratch" isn't the real artifact type.

I'm hoping that artifacts with a specific type will be created according to some spec from that artifact producer, and have the fields set consistently according to their spec (e.g. all Helm charts follow a Helm spec). From the listing we shouldn't care how the artifactType value was determined, only that it has a specific value that we want.

andaaron commented 1 year ago

@sudo-bmitch If you put it like this (all tooling will eventually converge to check artifactType first, or will have special handling for individual artifact specs), then it makes sense.

sudo-bmitch commented 1 year ago

@andaaron the goal of the phrasing is to say "check artifactType first, and fall back to using config.mediaType". Suggestions for better wording in the spec is welcome, because I'm not happy with it either.

andaaron commented 1 year ago

@andaaron the goal of the phrasing is to say "check artifactType first, and fall back to using config.mediaType". Suggestions for better wording in the spec is welcome, because I'm not happy with it either.

I'm fine with the wording as long as the other consumers of the image spec use the same rationale when reading a manifest. That was my concern.

jdolitsky commented 1 year ago

@mikebrow can I get a re-approve? (adding jons suggestion dismissed your review)

sudo-bmitch commented 1 year ago

This has been updated with the changes from today's meeting. PTAL.