dockershim: Return Labels as Info in ImageStatus.

[shlevy]

c6ddc74 added an Info field to
ImageStatusResponse when Verbose is true. This makes the image's
Labels available in that field, rather than unconditionally returning
an empty map.

What this PR does / why we need it:

This PR exposes an image's Labels through the CRI. In particular, I want this so I can write an ImageService wrapper that delegates all operations to a real ImageService but also, when the right Labels, ensures any needed nix store paths are present on the system when an image is pulled, enabling users to use nix for package distribution while still using containers for isolation and kubernetes for orchestration. In general, though, this should be useful for anything that wants to know about an image's Labels

Special notes for your reviewer:

I'd prefer to put this change into the Image protobuf type instead of putting it into Info (gated by Verbose or not, available in other requests like ListImages or not), but that would be a change to the protocol and it seems Info was introduced exactly for this purpose. If it's acceptable to put this into Image, I'll rework this.

If this change is acceptable, I will also do the work for cri-o, rktlet, frakti, and cri-containerd where applicable.

I have started the process for my employer to sign on to the CLA. I don't have reason to expect it to take long, but because there is more work to do if this change is desired I'd prefer if we can start review before that is completed.

Release note:

dockershim now makes an Image's Labels available in the Info field of ImageStatusResponse

[k8s-ci-robot]

Thanks for your pull request. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

📝 Please follow instructions at https://github.com/kubernetes/kubernetes/wiki/CLA-FAQ to sign the CLA.

It may take a couple minutes for the CLA signature to be fully registered; after that, please reply here with a new comment and we'll verify. Thanks.

---

• If you've already signed a CLA, it's possible we don't have your GitHub username or you're using a different email address. Check your existing CLA data and verify that your email is set on your git commits.
• If you signed the CLA as a corporation, please sign in with your organization's credentials at https://identity.linuxfoundation.org/projects/cncf to be authorized.
• If you have done the above and are still having issues with the CLA being reported as unsigned, please email the CNCF helpdesk: helpdesk@rt.linuxfoundation.org

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. I understand the commands that are listed here.

[cblecker]

/ok-to-test

[cblecker]

@shlevy Please review and sign the CLA: #58036 (comment)

[shlevy]

@cblecker I am waiting on my employer's guidelines for signing as an individual or as a corporation

[shlevy]

OK, the process is started by my employer and the CLA should be signed within a week or so. In the mean time, though, if this work is desirable there's more work I'd need to do for the other CRI server implementations, so if possible a high level review (taking into account my "notes for reviewer") would be appreciated. I understand if everything needs to wait for the CLA though!

[mtaufen]

/unassign
/assign @yujuhong

[shlevy]

OK, CLA finally came through. Rebasing now.

[shlevy]

/retest

[shlevy]

@cblecker How do I get the CLA check to run again?

[cblecker]

@shlevy The CLA check runs whenever the PR is updated. It's still reporting that you don't have a signed CLA. You may wish to check the top comment one more time to confirm you've followed all the needed steps.

[shlevy]

OK, I think CLA is finally all covered 😅

[shlevy]

Hmm, I don't really understand what's going on in that test failure, is that really related to this PR?

[cblecker]

/test pull-kubernetes-unit, flake #59426

[cblecker]

/retest

[yujuhong]

I'm okay with the change since it's gated by "verbose".
Each runtime implements the verbose response differently, so they can determine whether this is useful for them.

/lgtm

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: shlevy, yujuhong

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:

• pkg/kubelet/OWNERS [yujuhong]

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

[shlevy]

@yujuhong Any thoughts on this?

I'd prefer to put this change into the Image protobuf type instead of putting it into Info (gated by Verbose or not, available in other requests like ListImages or not), but that would be a change to the protocol and it seems Info was introduced exactly for this purpose. If it's acceptable to put this into Image, I'll rework this.

[Random-Liu]

@yujuhong This seems fine to me. :)

@shlevy I think we can consider adding label as official CRI fields when we have more use cases. The current use case seems more like an implementation detail for a specific use case. :)

[k8s-github-robot]

Automatic merge from submit-queue (batch tested with PRs 58171, 58036, 60540). If you want to cherry-pick this change to another branch, please follow the instructions here.

[ironhouzi]

@Random-Liu This feature is sorely needed by my use case:

We use containers for blackboxing trusted algorithms or data processors basically. We store definitions of inputs, how they map to commandline arguments to the executable and what outputs the processor is expected to produce. It makes a lot of sense to have this metadata as image labels instead of files inside the image, since the metadata is only needed by the container scheduler and not by the container runtime. Having the metadata and image bundled together is very nice in terms of portability.

[shlevy]

@Random-Liu What would be the appropriate process for proposing adding this as an official field of the Image protobuf type?