Skip to content
New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

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

Open
rchincha opened this issue May 28, 2024 · 7 comments

Comments

@rchincha
Copy link

rchincha commented May 28, 2024

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
Copy link
Author

@rchincha
Copy link
Author

@rchincha
Copy link
Author

@utam0k
Copy link
Member

utam0k commented May 29, 2024

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
Copy link
Author

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
Copy link
Member

utam0k commented Jun 16, 2024

^ 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
Copy link
Member

tianon commented Jun 19, 2024

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.

# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants