|
| 1 | +# OCI Registry as a Kubeflow Model Registry |
| 2 | + |
| 3 | +## Authors |
| 4 | + |
| 5 | +- Ramkumar Chinchani (Cisco) |
| 6 | +- _TBD_ |
| 7 | + |
| 8 | +## Maintainers |
| 9 | + |
| 10 | +- Ramkumar Chinchani (Cisco) |
| 11 | +- _TBD_ |
| 12 | + |
| 13 | +## Motivation |
| 14 | + |
| 15 | +According to the [Kubeflow 2023 |
| 16 | +survey](https://blog.kubeflow.org/kubeflow-user-survey-2023/), 44% of users |
| 17 | +identified Model Registry as one of the big gaps in the user’s ML Lifecycle |
| 18 | +missing from the Kubeflow offering. |
| 19 | + |
| 20 | + |
| 21 | + |
| 22 | +## Solution Overview |
| 23 | + |
| 24 | +[Open Container Initiative](https://opencontainers.org/) is a sibling (to CNCF) |
| 25 | +organization under [The Linux Foundation](https://www.linuxfoundation.org/) |
| 26 | +which has the container |
| 27 | +[runtime](https://github.com/opencontainers/runtime-spec), |
| 28 | +[image](https://github.com/opencontainers/image-spec) and |
| 29 | +[distribution](https://github.com/opencontainers/distribution-spec) |
| 30 | +specifications under its purvey which are vendor-neutral contracts that the Kubernetes |
| 31 | +ecosystem relies on for running, filesystem layout, and pushing and pulling of |
| 32 | +container images. |
| 33 | + |
| 34 | +However, recent developments in the OCI, specifically |
| 35 | +[_image_](https://github.com/opencontainers/image-spec/releases/tag/v1.1.0) and |
| 36 | +[_distribution_](https://github.com/opencontainers/distribution-spec/releases/tag/v1.1.0) |
| 37 | +spec **v1.1.0**, have included support for pushing arbitrary artifacts along |
| 38 | +with support for relationships between artifacts. |
| 39 | + |
| 40 | +## OCI v1.1.0 Conformant Registries |
| 41 | + |
| 42 | +The following are the highlights about OCI artifact registries. |
| 43 | + |
| 44 | +- Container images: these represent workloads and have been the traditional use case for an OCI conformant registry. |
| 45 | + |
| 46 | +- Artifacts: these represent arbitrary data (ML model data or additional |
| 47 | + metadata in this context) that can also be pushed and pulled from an OCI |
| 48 | + conformant registry. |
| 49 | + |
| 50 | +- Content-addressable: all data is organized as a Merkle DAG with sha256 hashed |
| 51 | + blobs. This bodes well for reproducibility. |
| 52 | + |
| 53 | +- Versioning: apart from the sha256 hash, all data can be tagged with a human-readable version. |
| 54 | + |
| 55 | +- Annotations: there is provision to append arbitrary annotations to any artifact. |
| 56 | + |
| 57 | +- References: an artifact can now be pushed along with a reference to another |
| 58 | + artifact (via the `Subject` field) which can be leveraged to address the data |
| 59 | + lineage use case. |
| 60 | + |
| 61 | + |
| 62 | +## References |
| 63 | + |
| 64 | +_TBD_ |
| 65 | + |
0 commit comments