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

Support MediaType on OCI Layers #357

Merged
merged 1 commit into from
Oct 25, 2017

Conversation

williammartin
Copy link

According to the image spec [1], descriptors should contain
media types. Support them on the returned BlobInfo for layers.

[1] https://github.com/opencontainers/image-spec/blob/master/descriptor.md

@runcom
Copy link
Member

runcom commented Oct 11, 2017

LGTM

thanks @williammartin

Approved with PullApprove

@williammartin
Copy link
Author

@runcom @mtrmac It looks like maybe with Github's flakiness that nothing has poked Travis to start building, can you kick this off?

@mtrmac
Copy link
Collaborator

mtrmac commented Oct 11, 2017

ACK in principle, but looking at the references in types.go, quite a few assume that BlobInfo only has Size and Digest; could you edit them to clarify whether/how they are expected to work with the MediaType value?

The code base so far tends to use MIME instead of Media, unlike Moby, to be more explicit about the authority/format, unless an external format mandates e.g. a JSON field name. See e.g. ManifestMIMEType instances in types.go. (Honestly not sure whether this matters all that much.)

As for kicking the tests, unsure how to do that.

@williammartin
Copy link
Author

Sure, probably if I change something the tests will get kicked off anyway. I'll try to figure out something more consistent.

@BooleanCat
Copy link

BooleanCat commented Oct 13, 2017

@mtrmac We've updated the BlobInfo related comments. Please take a look :)

Also, seems like Travis still hasn't triggered even with a new commit.

@BooleanCat
Copy link

It seems that Travis CI has marked this PR as "Abuse detected" and refuses to run tests. I've contacted Travis support.

@BooleanCat
Copy link

@runcom @mtrmac
Could you please trigger the Travis build?

Response from Travis:

Hi Thomas,
Thanks for writing in.

We have found a bug in our abuse detection system which has been flagging users wrongly.

We're working on fixing it.

In the meantime, I have marked off the user account containers as trusted, so that the abuse detection checks are not run for it at all.

Could you trigger another build and let us know if it works?

Happy building!

@williammartin
Copy link
Author

@BooleanCat I think you should just amend the commit and force push, which will retrigger the build.

@BooleanCat BooleanCat force-pushed the blobinfo-media-type branch 2 times, most recently from faa22e6 to e6e2c40 Compare October 16, 2017 07:53
@BooleanCat
Copy link

@mtrmac Tests are green, they failed once because of a cache loading error. so I re-triggered.

@tscolari
Copy link
Contributor

@mtrmac could you review this after their last change?
This is blocking the last story to enable OCI buildpacks on Cloudfoundry! 😃

Copy link
Collaborator

@mtrmac mtrmac left a comment

Choose a reason for hiding this comment

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

Sorry for the delay.

Two of the added comments document something not actually implemented; it’s perfectly fine to adjust the comments, let’s not block the working part on implementing things which nobody found urgently needed (yet).

[We do eventually want the MIME type updated e.g. after compressing an OCI layer during push. But again, by no means blocking this PR.]

types/types.go Outdated
@@ -156,6 +157,7 @@ type ImageDestination interface {
// PutBlob writes contents of stream and returns data representing the result (with all data filled in).
Copy link
Collaborator

Choose a reason for hiding this comment

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

The “all data filled in” is not currently true for return values of PutBlob; most (all?) implementations currently fill in only digest and size.

Same for ReapplyBlob.

(It would be nice if it were true eventually.)

types/types.go Outdated
@@ -260,7 +262,7 @@ type ManifestUpdateOptions struct {
// only to make writing struct literals possible.
type ManifestUpdateInformation struct {
Destination ImageDestination // and yes, UpdatedManifest may write to Destination (see the schema2 → schema1 conversion logic in image/docker_schema2.go)
LayerInfos []BlobInfo // Complete BlobInfos (size+digest) which have been uploaded, in order (the root layer first, and then successive layered layers)
LayerInfos []BlobInfo // Complete BlobInfos (size+digest+urls+mediatype+annotations) which have been uploaded, in order (the root layer first, and then successive layered layers)
Copy link
Collaborator

Choose a reason for hiding this comment

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

This is not currently true; copy.Image sets InformationOnly.LayerInfos based on one of

  • Image.LayerInfos, which is documented above as ”MediaType may be [only] optionally provided”, and says nothing about URLs/Annotations (in particular schema[12] LayerInfos does not set MediaType)
  • The return value of ReapplyBlob/PutBlob (which is supposed to have “all data filled in” but actually all implementations just set digest + size)

AFAICS LayerInfos is currently used only in the schema1→schema2 conversion, which really only the size, so for now just documenting these two fields might be fine.

types/types.go Outdated
@@ -249,7 +251,7 @@ type Image interface {

// ManifestUpdateOptions is a way to pass named optional arguments to Image.UpdatedManifest
type ManifestUpdateOptions struct {
LayerInfos []BlobInfo // Complete BlobInfos (size+digest+urls) which should replace the originals, in order (the root layer first, and then successive layered layers)
LayerInfos []BlobInfo // Complete BlobInfos (size+digest+urls+mediatype+annotations) which should replace the originals, in order (the root layer first, and then successive layered layers)
Copy link
Collaborator

Choose a reason for hiding this comment

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

This is not currently implemented that way.

Same as ManifestUpdateInformation.LayerInfos below, the URLs+MIME type + annotations are not currently available when called by copy.Image.

Also, the UpdatedImage implementations currently do not use the MIME type from this array (but they do use URLs+annotations). Changing the two lines would be trivial, but when copy.Image does not set the values, that would break things.

So, I guess, for now explicitly document that the MIME type is ignored?

According to the image spec [1], descriptors should contain
media types. Support them on the returned BlobInfo for layers.

[1] https://github.com/opencontainers/image-spec/blob/master/descriptor.md

Signed-off-by: Claudia Beresford <cberesford@pivotal.io>
Signed-off-by: William Martin <wmartin@pivotal.io>
Signed-off-by: Topher Bullock <cbullock@pivotal.io>
@BooleanCat
Copy link

@mtrmac We've addressed the comments above, let us know what you think.

tscolari added a commit to cloudfoundry/grootfs that referenced this pull request Oct 23, 2017
Unblocking the garden team while waiting for the PR to be merged.
containers/image#357

[#152029459]
@mtrmac
Copy link
Collaborator

mtrmac commented Oct 25, 2017

👍 Thanks!

Approved with PullApprove

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.

None yet

5 participants