search

opencontainers / distribution-spec

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

Specify accepted manifest types #373

Closed sajayantony closed 1 year ago

sajayantony commented 1 year ago

The distribution spec does not explicitly state the types of manifest supported and this PR helps clarify that so that when v1.1 of the spec is tagged, implementations should support all 3 manifest types if they are to claim conformance.

If there is a capability endpoint that calls out the version or manifest types then all three manifest types should be supported - refer - https://github.com/opencontainers/distribution-spec/issues/365

Signed-off-by: Sajay Antony sajaya@microsoft.com

sajayantony commented 1 year ago

my thinking was that it was located next to the statement about the properties like subject and blobs. Should we move this type list above the blobs statement.

sudo-bmitch commented 1 year ago

I'm fine with the location, but the phrasing implies that these are special manifests that must always be accepted, while registries may impose limits on other manifests. We went through that with the subject statement on the next line which is how the "otherwise valid" phrasing got added. We probably want some kind of wording that indicates the registry can still reject the manifest, but not because of the media type.

sajayantony commented 1 year ago

Do you have any recommended working and I'm happy to change as needed @sudo-bmitch

My goal was to ensure that when distribution 1.1 is released we clarify that the registry should support these media types that are tied with v1.1 of image spec without it being listed as an example.

Is there concern if we specify the types that MUST be supported? Another related issue was https://github.com/opencontainers/image-spec/issues/907

sudo-bmitch commented 1 year ago

Do you have any recommended working and I'm happy to change as needed @sudo-bmitch

The best I can come up with is adding "otherwise valid" but I'm not thrilled with it. It really feels like we need a common phrasing of things that registries can and cannot use when deciding to accept a manifest.

My goal was to ensure that when distribution 1.1 is released we clarify that the registry should support these media types that are tied with v1.1 of image spec without it being listed as an example.

Is there concern if we specify the types that MUST be supported?

I don't have any use cases myself, at least for index and image. I'm not sure if someone else wants to create a registry that supports the APIs but not the content from OCI. If that were to happen, I think it's fair for us to say they aren't an OCI conformant registry.

The artifact manifest gets into a gray area since we consider registries (partially?) 1.0 conformant even if they don't support all the features. Each of the conformance tests are also gated behind flags, so we'd need to work out what that looks like for manifest types. In 1.0 tests, we only test for the image manifest support, not even the index manifest, so this will be an expansion in the type of confidence tests we run.

sajayantony commented 1 year ago

Given yesterday's discussion and opinions of keeping distribution and image spec separate I'm inclined to closing this PR.

mikebrow commented 1 year ago

nod.. let's close and reopen this requirement at some future point