The Wayback Machine - https://web.archive.org/web/20221224185058/https://github.com/opencontainers/image-spec/pull/816
Skip to content
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

manifest: clarify failure modes for unknown layer types #816

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

tych0
Copy link
Member

@tych0 tych0 commented Dec 10, 2020

Per #803, there seems to be some confusion about how tools should fail when
they encounter unknown layer types. Container runtimes cannot satisfy the
bit about:

The final filesystem layout MUST match the result of
applying the layers to an empty
directory.

by ignoring layer types, so the spec is slightly in conflict with itself
here, by requiring runtimes both MUST apply all the layers and MUST ignore
layers that they cannot understand. Given that the behavior of runtimes
(and image tools like umoci) today is simply to fail if it gets a layer
type it doesn't understand here, let's clarify the behavior to that.

However, image transfer tools can safely ignore mime types they don't
understand (indeed, skopeo does this today); let's add the wiggle wording
about "cannot be processed" for all similar classes of tools which don't
actually need to inspect layer content.

Suggested-by: Sebastiaan van Stijn github@gone.nl
Signed-off-by: Tycho Andersen tycho@tycho.pizza

Per opencontainers#803, there seems to be some confusion about how tools should fail when
they encounter unknown layer types. Container runtimes cannot satisfy the
bit about:

   The final filesystem layout MUST match the result of
   [applying](layer.md#applying-changesets) the layers to an empty
   directory.

by ignoring layer types, so the spec is slightly in conflict with itself
here, by requiring runtimes both MUST apply all the layers and MUST ignore
layers that they cannot understand. Given that the behavior of runtimes
(and image tools like umoci) today is simply to fail if it gets a layer
type it doesn't understand here, let's clarify the behavior to that.

However, image transfer tools can safely ignore mime types they don't
understand (indeed, skopeo does this today); let's add the wiggle wording
about "cannot be processed" for all similar classes of tools which don't
actually need to inspect layer content.

Suggested-by: Sebastiaan van Stijn <github@gone.nl>
Signed-off-by: Tycho Andersen <tycho@tycho.pizza>
Copy link
Member

@giuseppe giuseppe left a comment

LGTM

For example, an image transport tool which does not unpack layers can
process layers with mime types it does not understand, since it does
not need to inspect the content of the layers. However, a runtime which
cannot unpack a layer MUST fail, since it cannot render the final
filesystem layout as described above.
Copy link
Member

@cyphar cyphar Feb 1, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

NIT: In the image-spec we break on sentence endings (one sentence per line) rather than wrapping at 80 columns.

Copy link

@Iliyan-33 Iliyan-33 left a comment

gh pr checkout 816

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
4 participants