KEP-4639: Update CRI API and workflow

[saschagrunert]

Updating the KEP after the merge of: https://github.com/kubernetes/kubernetes/pull/125659

This reflects the current state of the enhancement.

Refers to https://github.com/kubernetes/enhancements/issues/4639

PTAL @haircommander @mikebrow @mrunalp

[toVersus]

Can you fix typo in this example as well? s/oci.image/oci.reference/g https://github.com/kubernetes/enhancements/blob/0c770bcd89f53ae7d8a57fdf23b6df07b3978c4f/keps/sig-node/4639-oci-volume-source/README.md?plain=1#L339-L340

[saschagrunert]

@toVersus sure, fixed as suggested :+1:

[saschagrunert]

Seeing the move to reference in the pod spec.. Was the desire to move to using reference across the board as a more general term for these .. vs. ImageSpec image? If so maybe consider creating a ReferenceSpec type that is an ImageSpec type.. and using ReferenceSpec and reference in the message Mount{}. Later we can add additional fields to specify the params for artifact types, etc.

Goal for this PR is to reflect the current as-is implementation per https://github.com/kubernetes/cri-api/blob/a17496fa80c15a582444f49c77d019fced169e77/pkg/apis/runtime/v1/api.proto#L247-L255, we can add future enhancements on top of that later on, sure.

[mikebrow]

Seeing the move to reference in the pod spec.. Was the desire to move to using reference across the board as a more general term for these .. vs. ImageSpec image? If so maybe consider creating a ReferenceSpec type that is an ImageSpec type.. and using ReferenceSpec and reference in the message Mount{}. Later we can add additional fields to specify the params for artifact types, etc.

Goal for this PR is to reflect the current as-is implementation per https://github.com/kubernetes/cri-api/blob/a17496fa80c15a582444f49c77d019fced169e77/pkg/apis/runtime/v1/api.proto#L247-L255, we can add future enhancements on top of that later on, sure.

ok

[saschagrunert]

can/should we normalize the terminology used? The terminology used varies from OCI reference as an "image or artifact", OCI "object(s)", OCI "image", and OCI "artifact."

It's not clear if we are removing artifacts for this cycle and only implementing OCI image as is (including platform index selected images).. or keeping artifact typed OCI mages as a stretch goal ...

IOW when we just say OCI image do we mean "image or artifact" and when we say OCI object do we mean "one conceptual piece of content stored as blobs with an accompanying manifest, where manifest is a JSON document uploaded via the manifests endpoint." Object being the broadest term implying any manifest type. Image or Artifact implying an image manifest (selected or not from a platform index) or "content other than OCI container images .. packaged using the image manifest."

The KEP should follow the proposed vocabulary: https://github.com/kubernetes/enhancements/blob/7c97898249d1ec040610aead30d41bab18c3f9e4/keps/sig-node/4639-oci-volume-source/README.md?plain=1#L278-L297

Means that "OCI images and/or artifacts" are "OCI objects", while "OCI images" alone mostly refer to the existing implementation.

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: mikebrow, mrunalp, saschagrunert

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:

• ~~keps/sig-node/OWNERS~~ [mrunalp]

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