image-layout: Require blobs/refs to exist but allow them to be empty #459
Conversation
This file contains hidden or 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
The previous wording ("has" and "contains") was not clear enough to
avoid confusion [1]. I consider this PR to be a spec clarification,
and not a spec change, but others will probably disagree [2] (which is
why I think we need the clarification).
If you cared about running images from the layout, you'd need "and
there MUST be at least one unpackable ref" language. And then you
have to match the oci-layout version with the media types that were
unpackable when it was current (or is validity in the eye of the
validator?)... This is a bowl that I do not want to fathom ;).
Maybe folks are just using an image-layout to ship some missing blobs
(and have refs empty). I don't see any incentive to image-authors to
publish ref-less blobs and then pretend they are runnable, so I don't
see a need to get into the business of restricting refs.
Or maybe they're shipping some missing refs (and have blobs empty).
Maybe they expect all blobs to be fetched via the descriptor's 'urls'.
Those sound fine to me too, so I don't think we should be in the
business of restricting blobs (and we already have "The blobs
directory MAY be missing referenced blobs...").
I am fine with validation code *warning* users about either case
(e.g. "this image-layout has no refs" or "refs a, b, and c require
blobs which are not stored in this image-layout"), but I don't think
the spec should block either of those.
[1]: opencontainers#287
[2]: opencontainers/image-tools#83 (comment)
Signed-off-by: W. Trevor King <[email protected]>
Contributor
|
LGTM |
1 similar comment
Contributor
|
LGTM |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
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.
The previous wording (“has” and “contains”) was not clear enough to avoid confusion. I consider this PR to be a spec clarification, and not a spec change, but others will probably disagree (which is why I think we need the clarification).
If you cared about running images from the layout, you'd need “and there MUST be at least one unpackable ref” language. And then you have to match the oci-layout version with the media types that were unpackable when it was current (or is validity in the eye of the validator?)… This is a bowl that I do not want to fathom ;).
Maybe folks are just using an image-layout to ship some missing blobs (and have refs empty). I don't see any incentive to image-authors to publish ref-less blobs and then pretend they are runnable, so I don't see a need to get into the business of restricting refs.
Or maybe they're shipping some missing refs (and have blobs empty). Maybe they expect all blobs to be fetched via the descriptor's
urls. Those sound fine to me too, so I don't think we should be in the business of restricting blobs (and we already have “The blobs directory MAY be missing referenced blobs…”).I am fine with validation code warning users about either case (e.g. “this image-layout has no refs” or “refs a, b, and c require blobs which are not stored in this image-layout”), but I don't think the spec should block either of those.
Ping @q384566678 and @xiekeyang (for opencontainers/image-tools#83) and @runcom (for #287).