Project defines invalid OCI content

[sudo-bmitch]

From the current spec:

The model specification needs to consider two factors:

1. The model needs to be stored in the OCI registry and display the parameters of the model. So that the model should use
   the artifact extension to
   packaging content other than OCI image specification.
2. The model needs to be mounted by the container runtime as
   read only volumes based on the OCI Artifacts in Kubernetes 1.31+.
   Container runtimes can only pull OCI artifact that follows the OCI image specification.

Therefore, the model specification must be defined through the artifact extension based on the OCI image specification. It can be better compatible with the kubernetes ecosystem.

There is a misunderstanding here because of misinformation being spread from KEP-4639. There's an attempt to clear this up at kubernetes/enhancements#4897 (comment) but that hasn't been merged yet and someone should submit a PR to fix the blog post misinformation too.

The TL;DR of the KEP is they do not support OCI Artifacts, only OCI Images. To be an OCI Image, the config media type MUST be set to application/vnd.oci.image.config.v1+json. And from the OCI Artifact guidance, the media type MUST NOT use that value (since it is specific to OCI Images):

Content other than OCI container images MAY be packaged using the image manifest. When this is done, the config.mediaType value MUST be set to a value specific to the artifact type or the empty value.

The two goals of the project are currently incompatible with each other, and the result is an invalid definition that OCI conformant registries and other tooling have no obligation to support. If the project wants to have content mounted as a volume source in Kubernetes according to KEP-4639, then there is no new specification needed, the content is a simple OCI image with the model packaged inside a tar filesystem. If the project wants to define an OCI Artifact, then the config media type must be changed and you have the choice to define your own artifactType and layer media types.

Note that there is a desire from the KEP authors to support OCI Artifacts in the future, which will likely require a new KEP that specifies how filesystem attributes normally provided by tar would be defined.

[gaius-qi]

@saschagrunert Hey, what do you think about supporting OCI Model Spec or OCI Artifacts in the KEP-4639? I think to support OCI Artifacts requires handling various custom mediaTypes. If you want to supports OCI Model Spec or OCI Artifacts, I will redefine the mediaType, such as application/vnd.cnai.model.layer.v1.tar .

[gaius-qi]

@sudo-bmitch According to @saschagrunert reply => kubernetes/enhancements#4639 (comment)

CRI-O can support custom media types. I will put the definition of artifact types directly into media types, without considering the media types that are compatible with image volume when the container runtime pulls the image volume.

I think it can be a correct Model Spec definition based on OCI Artifacts.

[saschagrunert]

misinformation being spread from KEP-4639

That's a bit rough worded for my taste considering that we're going back and forth with the KEP. 🙃

The TL;DR of the KEP is they do not support OCI Artifacts, only OCI Images.

That's what the runtimes can currently do, but we can clearly built on top if that.

[sudo-bmitch]

misinformation being spread from KEP-4639

That's a bit rough worded for my taste considering that we're going back and forth with the KEP. 🙃

I avoided the term disinformation, because I don't think there's any malicious intent from the authors. I've just seen too many end users that have been mislead, and feel really bad for all the end users that reasonably assume that OCI Artifacts are currently supported. Those users have also been coming to OCI, e.g. we recently had a request to change the spec with a new layer media type so that their artifact content would be considered an OCI image that would then be required for runtimes to support. The sooner we can merge corrections to the KEP and blog posts, the fewer people will be mislead, so I'd like to do what it takes to expedite that.