-
Notifications
You must be signed in to change notification settings - Fork 662
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: provide guidance on SCRATCH descriptor (config and layer) #1023
Conversation
I would like feedback on whether to add |
+1 on adding the digest. I think it solidifies what an empty config is and clients/registries can optimize this if they haven’t already. |
4bcc39f
to
95b5dc7
Compare
updated PTAL |
I thought about that, but then the marshalling or string handling... I
figured just to provide the sum that can be compared. And include in
variable name that it's sha256 for _whenever_ we move on to something
else.
Instead I'll improve upon the comment to show that it's `{}`
|
95b5dc7
to
e978aea
Compare
Is there much difference between var ScratchConfig = imagespec.Descriptor{
Digest: `sha256:44136fa355b3678a1146ad16f7e8649e94fb4fc21fe77e8310c060f61caaff8a`,
Size: 2,
Data: []byte(`{}`),
} This then allows comparison directly against |
e978aea
to
68a742c
Compare
right on! |
68a742c
to
9642ef4
Compare
updated PTAL |
2174a9b
to
86570c6
Compare
updated PTAL |
I think #1025 supports this guidance. 👍 |
Adding this to 1.1 milestone as #999 would remove the artifact manifest and this would define how artifact authors can use the config without content. If there is any problem add this to 1.1 release please respond or we can bring this up in the call next week. |
7a8bdc6
to
1454d6b
Compare
updated, and including verbiage for |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm leaning towards moving most of the text into a "guidance" section, to make a clear separation between the spec and recommended usage of the spec. In the guidance I'd focus on an example with a config and artifact layer first, with the scratch example as a recommended solution only for extreme scenarios. We also need to clarify the deviation of the media type from the blob contents in some scenarios.
specs-go/v1/mediatype.go
Outdated
@@ -70,6 +70,9 @@ const ( | |||
// MediaTypeImageConfig specifies the media type for the image configuration. | |||
MediaTypeImageConfig = "application/vnd.oci.image.config.v1+json" | |||
|
|||
// MediaTypeImageScratch specifies the media type for a SCRATCH blob. | |||
MediaTypeImageScratch = "application/vnd.oci.example+json" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This should be a custom value for each implementation, so I don't think there's a way to include it in the spec.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Agree, there are 0 use cases for this.
specs-go/v1/manifest.go
Outdated
const ScratchDigestSHA256 = `sha256:44136fa355b3678a1146ad16f7e8649e94fb4fc21fe77e8310c060f61caaff8a` | ||
|
||
// ScratchDescriptor is a SCRATCH descriptor for Manifest's `config` when that manifest does not have a config to provide. | ||
func ScratchDescriptor() Descriptor { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd be interested in hearing the use cases for the full descriptor to be sure we aren't adding complexity that isn't needed.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it makes it easier for clients to create a base descriptor object. Its a good helper method.
Is there really a concern having this method? Hoping to get this or the @sudo-bmitch's PR through or we combine the 2 to and merge 999.
@sudo-bmitch I think the data of |
I like having the digest and the data, but the rest of the descriptor bothers me. It can't be compared since we don't know the media type, and other fields could be defined in the descriptor being compared. And it's a mix of an input (the digest) and an output (the returned blob content) in the same struct, so any usage of that feels awkward to me. See #1029 where I just set them as two const values instead. |
@@ -42,6 +42,12 @@ Unlike the [image index](image-index.md), which contains information about a set | |||
|
|||
If the manifest uses a different media type than the above, it MUST comply with [RFC 6838][rfc6838], including the [naming requirements in its section 4.2][rfc6838-s4.2], and MAY be registered with [IANA][iana]. | |||
|
|||
To set an effectively NULL or SCRATCH config and maintain portability the following is considered GUIDANCE. | |||
While an empty blob (`size` of 0) may be preferable, practice has shown that not to be ubiquitiously supported. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
practice has shown that not to be ubiquitiously supported.
This might not be a problem, because implementations do not need to unmarshal this "JSON" object (and the unmarshallized object is simply useless)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Practice has shown zero size blobs to fail.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
see #1025
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 <[email protected]>
fae4eb6
to
87f98aa
Compare
Ref: opencontainers#1025 Through the conversations between artifact manifest and standardizing the misuse of the image-manifest one of the topics was around when there is _not_ a `config` needed for the `layers`/blobs. Since the `config` is a REQUIRED field, it meant setting this to some valid value. This guidance intends to set a norm for a blob that need only be pushed to a registry a single time, and then save on round trips for all future SCRATCH configs, while also being most widely portability. to facilitate use by tools that import this reference code to identify this specific blob when working with an empty/scratch config blob and layer blob. This will utilize the same blob for both Signed-off-by: Vincent Batts <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've got a few nits that I'll put in #1029 later. This looks good to move forwards. Thanks!
Through the conversations between artifact manifest and standardizing the misuse of the image-manifest one of the topics was around when there is not a
config
needed for thelayers
/blobs, and if there was not alayer
needed. How best to be portable.Since the
config
is a REQUIRED field, it meant setting this to some valid value.This guidance intends to set a norm for a blob that need only be pushed to a registry a single time, and then save on round trips for all future SCRATCH configs, while also being most widely portability.
Signed-off-by: Vincent Batts [email protected]