Skip to content
New issue

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

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

Already on GitHub? Sign in 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.

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

No branches or pull requests

3 participants