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

IR-57: API changes for manifest list support #635

Merged
merged 3 commits into from
Apr 26, 2021
Merged

IR-57: API changes for manifest list support #635

merged 3 commits into from
Apr 26, 2021

Conversation

ricardomaraschini
Copy link
Contributor

This commits adds a proposal for Openshift's manifest list support.

Copy link
Contributor

@dmage dmage left a comment

Choose a reason for hiding this comment

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

Will we have changes in ImageStreamImport? ImageStreamLayers? Will it be possible to get ImageStreamImages only for top-level SHAs (i.e. for image A) or will it work for children manifests too (i.e. for images B, C, D)?


### Non-Goals

- Modify OpenShift's web console to support manifest lists.
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 say it should also be a goal. As well as improving oc describe. If we allow customers to create some objects, we should allow them to inspect them.

A non-goal: provide facilities to build manifest lists.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Added.


- Allow users to import manifest lists using `oc image-import`.
- Allow users to execute pull through using manifest lists.
- Make image pruner aware of manifest lists.
Copy link
Contributor

Choose a reason for hiding this comment

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

I would add:

  • Allow users to push manifest lists into the integrated registry.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Added.

in order to present them to users. When dealing with manifest lists not all
information will be presented back to the console (the Config portion of an
image is absent in a manifest list). Depending on how manifest lists support
is going to be implemented in the console a second request to the API may be
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 say the goal of this proposal is to define these API details.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Could we tag someone from Console team's here? I need to get someone from that side involved.

metav1.TypeMeta
metav1.ObjectMeta
DockerImageReference string
DockerImageMetadata DockerImage
Copy link
Contributor

Choose a reason for hiding this comment

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

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Addressed. Not sure from where I copy this anymore.

(i.e. Config) we can see nowadays in a regular Image.

Not all fields in an Image are relevant for a manifest list, therefore other
proposed change is to add an "omitempty" flag on `DockerImageLayers` property
Copy link
Contributor

Choose a reason for hiding this comment

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

I don't think this is a backward compatible change. Old clients (oc v4.(y-1).z) may expect them to be always present.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

What is the main source of concern here?

  1. DockerImageLayers being an empty slice or
  2. DockerImageLayers not even being presented


A second test would be very similar to this one but at this time leveraging
pull through. Podman currently supports managing manifest lists and we can
use its internals for step 2.
Copy link
Contributor

Choose a reason for hiding this comment

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

We also need to test that a manifest list can be mirrored into the integrated registry using oc image mirror.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Added.


### Non-Goals

- Modify OpenShift's web console to support manifest lists.
Copy link
Contributor

Choose a reason for hiding this comment

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

Another non-goal - Multiarch OpenShift builds which push a manifest list as output.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Added, thanks.

1. Deploy a temporary image registry.
2. Publish a manifest list containing images for different platforms.
3. Create an ImageStream object to import the published manifest list.
4. Create a Deployment using the ImageStream.
Copy link
Contributor

Choose a reason for hiding this comment

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

I think builds need to be included here as well. I'm pretty sure buildah can handle building from an image that references a manifest list, but we should verify that.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

"Make sure a build that leverages an image using ManifestList works"
Something like this?

Copy link
Contributor

Choose a reason for hiding this comment

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

yeah. more importantly, "using a manifestlist hosted in the internal registry" (it better already work for manifestlists in general)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I have added a new section with a test to validate this. Thanks.

@ricardomaraschini ricardomaraschini changed the title IR-57: API changes for manifest list support WIP - IR-57: API changes for manifest list support Mar 19, 2021
@openshift-ci-robot openshift-ci-robot added the do-not-merge/work-in-progress Indicates that a PR should not merge because it is a work in progress. label Mar 19, 2021
@ricardomaraschini
Copy link
Contributor Author

Will we have changes in ImageStreamImport? ImageStreamLayers? Will it be possible to get ImageStreamImages only for top-level SHAs (i.e. for image A) or will it work for children manifests too (i.e. for images B, C, D)?

With regards to ImageStreamImport

I have proposed a change to the output of an ImageStreamImport, the proposal is to return the "child images" on the Status field, please take a look.

With regards to ImageStreamLayers

I have added a note as we gonna have to include layers from the child images on this API as well. PTAL.

With regards to ImageStreamImage

As far as I understood this is used when "tagging" one ImageStreamTag from one ImageStream into another (or between two distinct ImageStreamTags in the same ImageStream), in my view it would stay as it is, we would allow this tagging to happen only at the upmost level (at the ManifestList level). We will need to allow users to describe the "child images" as well (e.g. oc get -o yaml isimage <imagestream>@<sha of a child image>) and I have added this to the proposal. What do you reckon on this regard?

@ricardomaraschini ricardomaraschini changed the title WIP - IR-57: API changes for manifest list support IR-57: API changes for manifest list support Mar 23, 2021
@openshift-ci-robot openshift-ci-robot removed the do-not-merge/work-in-progress Indicates that a PR should not merge because it is a work in progress. label Mar 23, 2021
Openshifft's internal registry will need to accept image pushes by SHA, not only by tag. The
difference here is that the registry is not supposed to create an Image object every time it
sees a push by SHA but only when it sees a push by tag. In the latter scenario the registry may
need to create more than one image (if the pushed manifest is of type manifest list).
Copy link
Contributor

Choose a reason for hiding this comment

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

Risk: the pruner won't see these images, the hard pruner doesn't know about its age and whether this manifest has been just uploaded for a manifest list.

@dmage
Copy link
Contributor

dmage commented Mar 25, 2021

I think this proposal is ready for a review by a broader audience.

/assign @bparees @smarterclayton

enhancements/manifestlist/manifestlist-support.md Outdated Show resolved Hide resolved

As an OpenShift user
I want to be able to automatically clean unused manifest lists
So that I can keep my storage resource usage under control
Copy link
Contributor

Choose a reason for hiding this comment

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

need more detail on how prune will work. If any image within the manifestlist is in use, will the full manifestlist be kept around? Or only if the manifestlist itself is referenced the manifestlist will be kept around?

or something in between? (if 2 of 3 images in the manifestlist are in use, the manifestlist is kept around but the unused image is removed from the manifestlist)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I think that the best way of dealing with this would be to maintain the whole struct consistent by not removing anything that is part of the manifest list. I have added a section to the proposal specifying this, PTAL.

/cc @dmage you may have some input on this regard.

Copy link
Contributor

Choose a reason for hiding this comment

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

keeping the entire manifestlist intact if any image it contains is ref'd makes sense to me.

1. Deploy a temporary image registry.
2. Publish a manifest list containing images for different platforms.
3. Create an ImageStream object to import the published manifest list.
4. Create a Deployment using the ImageStream.
Copy link
Contributor

Choose a reason for hiding this comment

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

yeah. more importantly, "using a manifestlist hosted in the internal registry" (it better already work for manifestlists in general)

This commits adds a proposal for Openshift's manifest list support.
ImageStream X -> Image A -> Image B
Image C
Image D

Copy link
Contributor

Choose a reason for hiding this comment

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

it's not clear to me what the relationship is between A,B,C,and D here.

are they all part of the same manifestlist? is B the base image for A? Is A a manifestlist that contains B,C, and D?

I think it's that last option, but it'd help to clarify the scenario.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yes, you are right. I will clarify it. The last option is the correct one.

@bparees
Copy link
Contributor

bparees commented Mar 31, 2021

/approve

@openshift-ci-robot
Copy link

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: bparees

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

@openshift-ci-robot openshift-ci-robot added the approved Indicates a PR has been approved by an approver from all required OWNERS files. label Mar 31, 2021
```

The output of the `oc describe isimage` command line will need to be changed to display
information present in the DockerImageManifests property of the parent Image.
Copy link
Contributor

Choose a reason for hiding this comment

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

/cc @soltysh

fyi, we want to update oc describe for some image related types

Copy link

Choose a reason for hiding this comment

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

No objections from my end.


Here the image that refers to the manifest list would be presented on `Image` property (as it is
today for regular manifests) while all inner manifests within the manifest list would be listed
in the `Manifests` slice.
Copy link
Contributor

@dmage dmage Apr 6, 2021

Choose a reason for hiding this comment

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

/cc @spadgett

fyi, ImageStreamImports are going to show more information about manifest lists, afaik Console uses ImageStreamImports.

@dmage
Copy link
Contributor

dmage commented Apr 26, 2021

No objections, so let's merge it.
/lgtm

@openshift-ci-robot openshift-ci-robot added the lgtm Indicates that a PR is ready to be merged. label Apr 26, 2021
@openshift-merge-robot openshift-merge-robot merged commit 52eb78e into openshift:master Apr 26, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
approved Indicates a PR has been approved by an approver from all required OWNERS files. lgtm Indicates that a PR is ready to be merged.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

8 participants