Skip to content

Conversation

@ktock
Copy link
Member

@ktock ktock commented Jan 31, 2023

Now the user of remote snapshotter labels appended by CRI plugin is not only stargz-snapshotter but also several remote snapshotter implementations in the community. (There is also discussion to use them from non-snapshotter tool moby/moby#44810)

Currently, the code is defined as private variables/functions so projects outside containerd need to copy-and-paste them. These clones aren't easy to maintain because they need to be copy-and-pasted again every time changes occur on the upstream code.
This PR exports remote snapshotter's label-related logic and tries to make it easier to maintain tools around remote snapshotters.

@thaJeztah
Copy link
Member

/cc @rumpl @tianon

@k8s-ci-robot k8s-ci-robot requested a review from tianon January 31, 2023 14:06
@k8s-ci-robot
Copy link

@thaJeztah: GitHub didn't allow me to request PR reviews from the following users: rumpl.

Note that only containerd members and repo collaborators can review this PR, and authors cannot review their own PRs.

Details

In response to this:

/cc @rumpl @tianon

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

// the target image and will be passed to snapshotters for preparing layers in
// parallel. Skipping some layers is allowed and only affects performance.
TargetImageLayersLabel = "containerd.io/snapshot/cri.image-layers"
)
Copy link
Member

Choose a reason for hiding this comment

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

Can we add a comment line to explain that these labels are not specific to CRI, but we have to retain "cri" in the label strings for historical reason?

@ktock
Copy link
Member Author

ktock commented Feb 1, 2023

/retest

Copy link
Member

@thaJeztah thaJeztah left a comment

Choose a reason for hiding this comment

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

Overall looks good (thanks!) I left some comments/suggestions; (most of) those were already in the existing code (and one of them definitely not needed for this PR), but perhaps now is a good opportunity to fix them up (no strong blockers though)

import (
"context"

containerdimages "github.com/containerd/containerd/images"
Copy link
Member

Choose a reason for hiding this comment

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

Looks like in most places (except for 1 or 2 where we must use an alias) we don't use an alias for this; so I would suggest not aliasing the import here.

containerdimages "github.com/containerd/containerd/images"
"github.com/containerd/containerd/labels"
"github.com/containerd/containerd/log"
imagespec "github.com/opencontainers/image-spec/specs-go/v1"
Copy link
Member

Choose a reason for hiding this comment

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

In most places, we use ocispec as alias for this one. We should align those aliases for places where we use a different alias, but as this is a new package, it would be good to change this to ocispec.

// descriptors. The returned list contains as many digests as possible as well
// as meets the label validation.
func getLayers(ctx context.Context, key string, descs []imagespec.Descriptor, validate func(k, v string) error) (layers string) {
var item string
Copy link
Member

Choose a reason for hiding this comment

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

Looks like this variable is only used inside the loop, and inside the if branch. Probably better to define it inside the loop as a local variable?

var item string
for _, l := range descs {
if containerdimages.IsLayerType(l.MediaType) {
item = l.Digest.String()
Copy link
Member

Choose a reason for hiding this comment

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

(see comment above)

Suggested change
item = l.Digest.String()
item := l.Digest.String()

}
// This avoids the label hits the size limitation.
if err := validate(key, layers+item); err != nil {
log.G(ctx).WithError(err).WithField("label", key).Debugf("%q is omitted in the layers list", l.Digest.String())
Copy link
Member

Choose a reason for hiding this comment

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

As we're already using a structured log, perhaps set digest as a field, instead of Debugf()?

Suggested change
log.G(ctx).WithError(err).WithField("label", key).Debugf("%q is omitted in the layers list", l.Digest.String())
log.G(ctx).WithError(err).WithField("label", key).WithField("digest", l.Digest.String()).Debug("omitting digest in the layers list")

How likely is this to happen? Should this be an Info() or would that be too noisy?

for _, tt := range tests {
tt := tt
t.Run(tt.name, func(t *testing.T) {
var sampleLayers []imagespec.Descriptor
Copy link
Member

Choose a reason for hiding this comment

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

nit: not super important for this size, but this could be;

Suggested change
var sampleLayers []imagespec.Descriptor
sampleLayers := make([]imagespec.Descriptor, 0, tt.layersNum)

}
c.Annotations[TargetRefLabel] = ref
c.Annotations[TargetLayerDigestLabel] = c.Digest.String()
c.Annotations[TargetImageLayersLabel] = getLayers(ctx, TargetImageLayersLabel, children[i:], labels.Validate)
Copy link
Member

Choose a reason for hiding this comment

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

This can be done in a follow-up, but we should look at getLayers() at it looks like we're effectively doing the same handling for every child (but each time with a shorter list). I have a feeling we can optimise some of that (but need to have a closer look, and not important for now).

Copy link
Member Author

Choose a reason for hiding this comment

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

Thank you for the suggestion. Let's work on it in a follow-up.

Copy link
Member

Choose a reason for hiding this comment

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

👍 I didn't fully look at it, or if it would save a lot of allocations, so it definitely may be a "micro optimisation", so not a top-priority (could be a "lunch-time" exercise for fun).

@ktock
Copy link
Member Author

ktock commented Feb 1, 2023

@thaJeztah Thank you for the review. Fixed the patch.

Copy link
Member

@thaJeztah thaJeztah left a comment

Choose a reason for hiding this comment

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

LGTM, thank you!

@thaJeztah
Copy link
Member

I wonder if this could make sense for a 1.6 patch release if it would help transitioning. Overall it seems fairly low risk, but it's not a "bug-fix" or "security-fix", so not sure if it would qualify (would be nice though!)

Copy link
Member

@estesp estesp left a comment

Choose a reason for hiding this comment

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

LGTM

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.

7 participants