Clarify ignore language, ensure future compat#1028
Clarify ignore language, ensure future compat#1028AaronFriel wants to merge 2 commits intoopencontainers:mainfrom
Conversation
01989ff to
c3acbaf
Compare
Signed-off-by: Aaron Friel <mayreply@aaronfriel.com>
c3acbaf to
98bc71b
Compare
| It is set to true if this history item doesn't correspond to an actual layer in the rootfs section (for example, Dockerfile's [ENV](https://docs.docker.com/engine/reference/builder/#/env) command results in no change to the filesystem). | ||
|
|
||
| Any extra fields in the Image JSON struct are considered implementation specific and MUST be ignored by any implementations which are unable to interpret them. | ||
| Any extra fields in the Image JSON struct are considered implementation specific and MUST NOT generate an error by any implementations which are unable to interpret them. |
There was a problem hiding this comment.
This is specific to registry implementations, right? (as opposed to "client implementations" which feels included in that "any")
In other words, the intent is that we expect Docker Hub and friends to accept Helm charts, but it's still 100% reasonable and expected for the Docker CLI/Engine to bail with a helpful error if you try to docker run a Helm chart. 😅
There was a problem hiding this comment.
Yeah, hm.
An example of a client that's in-the-middle is, e.g., oras copy. I expect ORAS to faithfully copy manifests and blobs from one registry to another. But I suppose that's a "MAY".
|
Related: #902 |
0000ce5 to
7532c8f
Compare
Signed-off-by: Aaron Friel <mayreply@aaronfriel.com>
7532c8f to
047d81c
Compare
|
@sudo-bmitch @tianon PTAL, I've amended this in two ways: Grandfathering OCI 1.1-rc behaviorDocumenting deviation from the This preserves the intent of the This change should not conflict with #1029, except #1029 should be changed to indicate that this "SCRATCH" specification exists only for artifacts using image manifests and going forward, implementations SHOULD use artifact manifest. Distinguishing behavior of clients vs registries/proxiesImplementations fall into two categories:
|
|
PTAL |
Implementations lack any information to determine whether the `config` property of an Image Manifest describes the `artifactType` of the manifest, or the media type of the referenced content. This is necessitated by the removal of artifact manifest (opencontainers#999) and addition of scratch descriptors (opencontainers#1023) to support artifacts. If opencontainers#999 is withdrawn, this pull request should be withdrawn as well and opencontainers#1028 considered instead.
Implementations lack any information to determine whether the `config` property of an Image Manifest describes the `artifactType` of the manifest, or the media type of the referenced content. This is necessitated by the removal of artifact manifest (opencontainers#999) and addition of scratch descriptors (opencontainers#1023) to support artifacts. If opencontainers#999 is withdrawn, this pull request should be withdrawn as well and opencontainers#1028 considered instead. Signed-off-by: Aaron Friel <mayreply@aaronfriel.com>
|
Closing in favor of #1030 |
The usage of "ignore[d]" appears may have resulted in ambiguous parsing of the spec.
One interpretation is that OCI 1.0 already required registries to accept Artifact and future media types, and implementations - clients and registries - that fail to handle arbitrary media types for blobs, arbitrary media types for image configs.