image.go:change out.Print to fmt.Errorf #83
Conversation
Signed-off-by: zhouhao <[email protected]>
|
On Sun, Nov 13, 2016 at 10:35:56PM -0800, Zhou Hao wrote:
Previous discussion in opencontainers/image-spec#287 (maybe moved to #15) and 1. I don't see |
If not change, we are in accordance with the above command to verify an empty folder, it will only display warning, but it will still be OK, this is wrong |
|
On Mon, Nov 14, 2016 at 05:27:12PM -0800, Zhou Hao wrote:
You can have warnings in a valid image (that's the difference between |
|
I debug it. the Warning happens when oci layout lack
So I think it should return error instead warning in this case. LGTM |
|
On Tue, Nov 15, 2016 at 07:08:13PM -0800, xiekeyang wrote:
Are you interpreting “contains descriptors” as “MUST contain at least |
|
@xiekeyang If |
I think we are discussing if |
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]>
|
On Tue, Nov 15, 2016 at 10:51:37PM -0800, xiekeyang wrote:
I've filed opencontainers/image-spec#459 to add clarity to the When you give validation an explicit list of refs, it's fairly clear When you just give it an image-layout, it's not clear (to me) that you |
|
As most folks accept opencontainers/image-spec#459, this PR should be closed. |
|
On Wed, Nov 16, 2016 at 06:32:32PM -0800, xiekeyang wrote:
I think there may still be room for improved validation here if we can |
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/image-spec#287
[2]: opencontainers/image-tools#83 (comment)
Signed-off-by: W. Trevor King <[email protected]>
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/image-spec#287
[2]: opencontainers/image-tools#83 (comment)
Signed-off-by: W. Trevor King <[email protected]>
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/image-spec#287
[2]: opencontainers/image-tools#83 (comment)
Signed-off-by: W. Trevor King <[email protected]>
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/image-spec#287
[2]: opencontainers/image-tools#83 (comment)
Signed-off-by: W. Trevor King <[email protected]>
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/image-spec#287
[2]: opencontainers/image-tools#83 (comment)
Signed-off-by: W. Trevor King <[email protected]>
4 participants
I think we should return an error here, if it is to use WARING, then the validate function will return nil, and ultimately make the verification results are wrong
Signed-off-by: zhouhao [email protected]