-
Notifications
You must be signed in to change notification settings - Fork 475
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
IR-57: API changes for manifest list support #635
Conversation
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.
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. |
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 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.
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.
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. |
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 would add:
- Allow users to push manifest lists into the integrated registry.
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.
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 |
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 say the goal of this proposal is to define these API details.
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.
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 |
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.
DockerImageMetadata
is runtime.RawExtension
: https://github.com/openshift/api/blob/a9e731090f5ed361e5ab887d0ccd55c1db7fc633/image/v1/types.go#L41
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.
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 |
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 don't think this is a backward compatible change. Old clients (oc v4.(y-1).z) may expect them to be always present.
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.
What is the main source of concern here?
DockerImageLayers
being an empty slice orDockerImageLayers
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. |
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.
We also need to test that a manifest list can be mirrored into the integrated registry using oc image mirror
.
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.
Added.
|
||
### Non-Goals | ||
|
||
- Modify OpenShift's web console to support manifest lists. |
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.
Another non-goal - Multiarch OpenShift builds which push a manifest list as output.
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.
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. |
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 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.
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.
"Make sure a build that leverages an image using ManifestList works"
Something like this?
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.
yeah. more importantly, "using a manifestlist hosted in the internal registry" (it better already work for manifestlists in general)
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 have added a new section with a test to validate this. Thanks.
With regards to ImageStreamImportI 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 ImageStreamLayersI have added a note as we gonna have to include layers from the child images on this API as well. PTAL. With regards to ImageStreamImageAs 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. |
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). |
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.
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.
I think this proposal is ready for a review by a broader audience. /assign @bparees @smarterclayton |
|
||
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 |
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.
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)
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.
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.
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. |
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.
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 | ||
|
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.
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.
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.
Yes, you are right. I will clarify it. The last option is the correct one.
/approve |
[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 |
``` | ||
|
||
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. |
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.
/cc @soltysh
fyi, we want to update oc describe
for some image related types
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.
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. |
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.
/cc @spadgett
fyi, ImageStreamImports are going to show more information about manifest lists, afaik Console uses ImageStreamImports.
No objections, so let's merge it. |
This commits adds a proposal for Openshift's manifest list support.