Add manifest digest annotation for snapshotters#4610
Add manifest digest annotation for snapshotters#4610AkihiroSuda merged 1 commit intocontainerd:masterfrom shahzzzam:samashah/add-annotations
Conversation
Signed-off-by: Samarth Shah <[email protected]>
|
Hi @shahzzzam. Thanks for your PR. I'm waiting for a containerd member to verify that this patch is reasonable to test. If it is, they should reply with Once the patch is verified, the new status will be reflected by the I understand the commands that are listed here. DetailsInstructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
|
Build succeeded.
|
|
carry over from: containerd/cri#1585 where derek had the following question...
|
|
@dmcgowan makes sense. I renamed it to |
cpuguy83
left a comment
There was a problem hiding this comment.
This LGTM, but I am very close to this change.
The idea here is that the custom snapshotter needs the context of all the layers to know if it has the data available or the layer needs to be pulled to the node.
|
@shahzzzam LGTM about this change:+1: but I'm curious about which (and how) metadata in the manifest are consumed in your snapshotter. |
|
Any updates on this? |
ktock
left a comment
There was a problem hiding this comment.
LGTM
And I also agree with that we should seek a cleaner way to pass metadata from client to the snapshotter (maybe after this patch).
Possible solutions:
- Enabling to filter snapshot labels in config.toml (easier) or
- storing an all-in-one JSON blob (like the following) to the content store and pass only a digest label of that JSON blob to the snapshotter (maybe requires further discussion)
type SnapshotTarget struct {
ImageRef string `json:"image_ref"`
LayerDesc ocispec.Descriptor `json:"layer_desc"`
ManifestDesc ocispec.Descriptor `json:"manifest_desc"`
Platform ocispec.Platform `json:"platform"`
}WDYT? @dmcgowan
|
@ktock in the 1st solution the snapshotters will only have to parse the labels. In the 2nd solution, they will have to connect to |
|
Ping |
Yes. 1st one won't require any changes to the snapshotters. Users just add some filter expression (or label key names, etc) to the config.toml, based on the snapshoter they want to use. This improves the current default behaviour where many labels are appended to snapshots even if users don't use remote snapshots.
Yes. |
|
@ktock Sure, i am interested and can take a look at it later. For now, can you please help approve and merge this change? |
|
/ok-to-test |
|
We'd like to backport this change since it's necessary for Azure's snapshotter. |
|
@cpuguy83 Can you please help us backport this to 1.4? |
|
this was cherry-picked in containerd/cri#1609, but still needs a revendor of containerd/cri |
Signed-off-by: Samarth Shah [email protected]
We leverage stargz-based snapshotter and have implemented our own Filesystem interface. We need the image digest to get some metadata for the image itself.
cc: @cpuguy83 @juliusl @northtyphoon @mikebrow