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

/ok-to-test

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

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

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!

/unassign
/assign @yujuhong

OK, CLA finally came through. Rebasing now.

/retest

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

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

OK, I think CLA is finally all covered 😅

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

/test pull-kubernetes-unit, flake #59426

/retest

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

[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

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

@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. :)

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.

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

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