[KEP-4639] Update CRI API and workflow

[saschagrunert]

Updating the KEP after the merge of: kubernetes/kubernetes#125659

This reflects the current state of the enhancement.

Refers to #4639

PTAL @haircommander @mikebrow @mrunalp

[toVersus]

Can you fix typo in this example as well? s/oci.image/oci.reference/g

enhancements/keps/sig-node/4639-oci-volume-source/README.md

Lines 339 to 340 in 0c770bc

	oci:
	image: "example.com/my-image:latest"

[saschagrunert]

@toVersus sure, fixed as suggested 👍

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

[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

[mikebrow]

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

[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:

enhancements/keps/sig-node/4639-oci-volume-source/README.md

Lines 278 to 297 in 7c97898

	### Vocabulary: OCI Images, Artifacts, and Objects
	**OCI Image ([spec](https://github.com/opencontainers/image-spec/blob/main/spec.md)):**
	- A container image that conforms to the Open Container Initiative (OCI) Image Specification.
	It includes a filesystem bundle and metadata required to run a container.
	- Consists of multiple layers (each layer being a tarball), a manifest (which lists the layers), and a config file
	(which provides configuration data such as environment variables, entry points, etc.).
	- **Use Case:** Used primarily for packaging and distributing containerized applications.
	**OCI Artifact ([guidance](https://github.com/opencontainers/image-spec/blob/main/artifacts-guidance.md)):**
	- An artifact describes any content that is stored and distributed using the OCI image format.
	It includes not just container images but also other types of content like Helm charts, WASM modules, machine learning models, etc.
	- Artifacts use the same image manifest and layer structure but may contain different types of data
	within those layers. The artifact manifest can have media types that differ from those in standard container images.
	- **Use Case:** Allows the distribution of non-container content using the same infrastructure and tools developed for OCI images.
	**OCI Object:**
	- Umbrella term encompassing both OCI images and OCI artifacts. It represents
	any object that conforms to the OCI specifications for storage and
	distribution and can be represented as file or filesystem by an OCI container runtime.

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

[mikebrow]

LGTM

[mrunalp]

/lgtm

[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

Details

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