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: provide guidance on SCRATCH descriptor (config and layer) #1023

Merged
merged 1 commit into from
Mar 10, 2023

Conversation

vbatts
Copy link
Member

@vbatts vbatts commented Feb 12, 2023

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, and if there was not a layer 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 vbatts@hashbangbash.com

@vbatts
Copy link
Member Author

vbatts commented Feb 12, 2023

I would like feedback on whether to add sha256:44136fa355b3678a1146ad16f7e8649e94fb4fc21fe77e8310c060f61caaff8a as a const in ./specs-go/v1/manifest.go

manifest.md Outdated Show resolved Hide resolved
@sajayantony
Copy link
Member

+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.

@vbatts
Copy link
Member Author

vbatts commented Feb 13, 2023

updated PTAL

specs-go/v1/manifest.go Outdated Show resolved Hide resolved
@vbatts
Copy link
Member Author

vbatts commented Feb 13, 2023 via email

@tianon
Copy link
Member

tianon commented Feb 13, 2023

Is there much difference between v1.ScratchConfigDigestSHA256 and v1.ScratchConfig.Digest? (which is then also a string, but a typed string with more helpful methods?)

var ScratchConfig = imagespec.Descriptor{
	Digest: `sha256:44136fa355b3678a1146ad16f7e8649e94fb4fc21fe77e8310c060f61caaff8a`,
	Size:   2,
	Data:   []byte(`{}`),
}

This then allows comparison directly against .Digest (as a string, which it is), but you can then push it more trivially if you want/need to (and there's a descriptor that's basically ready-to-use, although since it's a struct it can't be const because Go 🙈).

@sajayantony
Copy link
Member

sajayantony commented Feb 13, 2023

@vbatts When we are adding the digest as a const, shouldn't the actual data value also be present. Some feel @tianon's proposal helps others consume this. Basically there is a scratchDescriptor :)

@vbatts
Copy link
Member Author

vbatts commented Feb 13, 2023

right on!

@vbatts
Copy link
Member Author

vbatts commented Feb 13, 2023

updated PTAL

specs-go/v1/manifest.go Outdated Show resolved Hide resolved
@vbatts vbatts force-pushed the scratch_config branch 2 times, most recently from 2174a9b to 86570c6 Compare February 16, 2023 10:31
@vbatts
Copy link
Member Author

vbatts commented Feb 16, 2023

updated PTAL

@brackendawson
Copy link

I think #1025 supports this guidance. 👍

sajayantony
sajayantony previously approved these changes Feb 16, 2023
manifest.md Outdated Show resolved Hide resolved
@sajayantony
Copy link
Member

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.

@sajayantony sajayantony added this to the v1.1 milestone Feb 24, 2023
@vbatts vbatts force-pushed the scratch_config branch 3 times, most recently from 7a8bdc6 to 1454d6b Compare February 24, 2023 22:24
@vbatts vbatts changed the title manifest: provide guidance on SCRATCH config descriptor manifest: provide guidance on SCRATCH descriptor (config and layer) Feb 24, 2023
@vbatts
Copy link
Member Author

vbatts commented Feb 24, 2023

updated, and including verbiage for layers. PTAL

Copy link
Contributor

@sudo-bmitch sudo-bmitch left a 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.

@@ -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"
Copy link
Contributor

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.

Copy link
Contributor

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.

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 {
Copy link
Contributor

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.

Copy link
Member

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.

@sajayantony
Copy link
Member

sajayantony commented Feb 25, 2023

I'm leaning towards moving most of the text into a "guidance" section

@sudo-bmitch I think the data of {} and hash being in the go files are helpful and will avoid a lot of inconsistencies when clients create this and coming back to spec for the hash/data can be avoided. Does that sound reasonable?

@sudo-bmitch
Copy link
Contributor

sudo-bmitch commented Feb 25, 2023

I'm leaning towards moving most of the text into a "guidance" section

@sudo-bmitch I think the data of {} and hash being in the go files are helpful and will avoid a lot of inconsistencies when clients create this and coming back to spec for the hash/data can be avoided. Does that sound reasonable?

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.
Copy link
Member

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)

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.

Copy link
Member Author

Choose a reason for hiding this comment

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

see #1025

AaronFriel added a commit to AaronFriel/image-spec that referenced this pull request Mar 2, 2023
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.
AaronFriel added a commit to AaronFriel/image-spec that referenced this pull request Mar 2, 2023
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 <mayreply@aaronfriel.com>
@vbatts vbatts force-pushed the scratch_config branch 2 times, most recently from fae4eb6 to 87f98aa Compare March 10, 2023 16:27
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 <vbatts@hashbangbash.com>
Copy link
Contributor

@sudo-bmitch sudo-bmitch left a 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!

@sudo-bmitch sudo-bmitch merged commit 2a860ae into opencontainers:main Mar 10, 2023
@vbatts vbatts deleted the scratch_config branch April 6, 2023 18:00
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

8 participants