Initial commit for OCI dist spec v1.1.0 agent support

[rchincha]

What this PR does / why we need it:

Initial commit for OCI dist spec v1.1.0 agent support

Partially addresses https://github.com/kubeflow/community/pull/682

OCI image and distribution specs v1.1.0 has added support for pushing
and pulling arbitrary artifacts to a conformant registry, and not just
container images.

Since a registry is already needed to deploy inference workloads as
containers, and that it would be desirable to avoid another piece of
infrastructure just to store inference data, a OCI conformant registry
could become that ideal store to combine and colocate both use cases.

This plugin adds that support.

https://kserve.github.io/website/latest/modelserving/storage/storagecontainers/

References:

https://opencontainers.org/posts/blog/2024-03-13-image-and-distribution-1-1/

Which issue(s) this PR fixes (optional, in fixes #<issue number>(, fixes #<issue_number>, ...) format, will close the issue(s) when PR gets merged):
Fixes #

kubeflow/community#682

Type of changes
Please delete options that are not relevant.

• Bug fix (non-breaking change which fixes an issue)
• [*] New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• [*] This change requires a documentation update

Feature/Issue validation/testing:

Please describe the tests that you ran to verify your changes and relevant result summary. Provide instructions so it can be reproduced.
Please also list any relevant details for your test configuration.

• Deploy a conformant registry such as (zot), push model data and then deploy a workload that consumes the data.

• Logs

Special notes for your reviewer:

1. Please confirm that if this PR changes any image versions, then that's the sole change this PR makes.

Checklist:

• Have you added unit/e2e tests that prove your fix is effective or that this feature works?
• Has code been commented, particularly in hard-to-understand areas?
• Have you made corresponding changes to the documentation?

Release note:

[oss-prow-bot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: rchincha
Once this PR has been reviewed and has the lgtm label, please assign yuzisun for approval by writing /assign @yuzisun in a comment. For more information see:The Kubernetes Code Review Process.

The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

• OWNERS

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

[rchincha]

Cross-posting here ...

https://kccnceu2024.sched.com/event/1YeLi
^ This idea is spreading around I suppose ... https://github.com/kubecon EU 2024

[lizzzcai]

Hi @rchincha , glad to see this will be supported in KServe. Just want to check is there a plan to support it in storage initializer in this PR? (like what I have previously commented here). what is the difference between storage initializer and agent?

[terrytangyuan]

Could you update the PR description?

[rchincha]

Hi @rchincha , glad to see this will be supported in KServe. Just want to check is there a plan to support it in storage initializer in this PR? (like what I have previously commented here). what is the difference between storage initializer and agent?

@lizzzcai Thanks for pointing out #3043 - lots of relevant discussion there. I am still learning about kserve so hazarding a possiblly incorrect guess. This PR should give the ability to serve models/artifacts from a OCI registry - OCI dist-spec v1.1.0 supports arbitrary artifacts. An example is perhaps this: https://kserve.github.io/website/0.7/modelserving/storage/s3/s3/

There is still a kubeflow workflow to push artifacts into a OCI registry to consider.

[rchincha]

Could you update the PR description?

Done, pls take a look.

[rhuss]

Modelcars also use oci:// as a schema prefix, so that might be conflicting here. Modelcars in fact, are conventional OCI images as they have also an active component for keeping a container alive (notably sleep and also a ln -s for creating the symbolic link in the emptyDir volume to point to the model data).

I'm not sure how the PR proposed here infers with the logic of the modelcar as defined in the storage initializer.

[rchincha]

The images here are going to be stored from a OCI artifact registry, so indeed they are also oci images. The question then is the transport schema. Maybe "oci-registry://" similar to "model-registry://"?