performance: how can runtime-spec incorporate non container image OCI artifacts lifecycle?

[rchincha]

Requirements from various communities:

1. AI/ML - large models (several GBs), to be pulled and cached and made available to container namespaces.
2. WASM - runnable non-container images

[rchincha]

opencontainers/distribution-spec#536

[rchincha]

https://docs.google.com/document/d/1Bs4fnP8rhPMaoPoLSYVvuRq-z9vkGPQ0rKbmfH4I7js/edit#heading=h.xw1gqgyqs5b
(cross-posted)
^ from the kubeflow community

[rchincha]

opencontainers/image-spec#1190

[utam0k]

AI/ML - large models (several GBs), to be pulled and cached and made available to container namespaces.

What should we do from the runtime spec side?

WASM - runnable non-container images

In my opinion, it's tough to cover all non-container image types in OCI Runtime Spec.

[rchincha]

runtime spec already assumes a bundle to pivot_root to, so maybe there is nothing to do here.

However, perhaps to be aware (currently ideas/possibilities)
opencontainers/image-spec#1191 (appears outside scope of this spec)

https://github.com/containerd/runwasi
^ would be ideal to select a runtime off of artifactType (again appears outside scope of this spec)

[utam0k]

^ would be ideal to select a runtime off of artifactType (again appears outside scope of this spec)

If you want us to do it, please update the issue or send out the PR.

[tianon]

I agree this is probably out of scope here; Docker, containerd, and even k8s fall somewhere between image and runtime/outside runtime. Image is mostly about how to represent the bits/what they mean and runtime assumes they're unpacked and layered already in a fully opaque way (as noted above).

On that note though, I believe that containerd already has the primitives necessary for this, and for Docker we've got a proposal at moby/moby#30449 that I haven't seen any active maintainers opposed to -- it just needs an implementation (contributions very welcome). I believe it's even already implemented in BuildKit.