You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
performance: how can runtime-spec incorporate non container image OCI artifacts lifecycle? #1254
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.
Activity
rchincha commentedon May 28, 2024
opencontainers/distribution-spec#536
rchincha commentedon May 28, 2024
https://docs.google.com/document/d/1Bs4fnP8rhPMaoPoLSYVvuRq-z9vkGPQ0rKbmfH4I7js/edit#heading=h.xw1gqgyqs5b
(cross-posted)
^ from the kubeflow community
rchincha commentedon May 28, 2024
opencontainers/image-spec#1190
utam0k commentedon May 29, 2024
What should we do from the runtime spec side?
In my opinion, it's tough to cover all non-container image types in OCI Runtime Spec.
rchincha commentedon May 29, 2024
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 commentedon Jun 16, 2024
If you want us to do it, please update the issue or send out the PR.
tianon commentedon 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.