manifest: clarify failure modes for unknown layer types #816
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
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>
cyphar
reviewed
Feb 1, 2021
Comment on lines
+65
to
+69
| 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. |
There was a problem hiding this comment.
NIT: In the image-spec we break on sentence endings (one sentence per line) rather than wrapping at 80 columns.
This comment was marked as off-topic.
This comment was marked as off-topic.
Sorry, something went wrong.
|
The problem text has been changed from:
to:
That may resolve the underlying concerns here. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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