Allow empty OCI configs for artifacts #2279
Comments
|
No, parsing the empty artifact as an image type just doesn’t make sense. What is failing? That should probably not be calling (I’m not at all saying that the current code is correct or sufficient, it’s just that without any more context this seems to be not the right approach.) |
|
So workflow wise, a current artifact push using ORAS: Results in the following manifest: {
"schemaVersion": 2,
"mediaType": "application/vnd.oci.image.manifest.v1+json",
"artifactType": "application/vnd.unknown.artifact.v1",
"config": {
"mediaType": "application/vnd.oci.empty.v1+json",
"digest": "sha256:44136fa355b3678a1146ad16f7e8649e94fb4fc21fe77e8310c060f61caaff8a",
"size": 2,
"data": "e30="
},
"layers": [
{
"mediaType": "application/vnd.oci.image.layer.v1.tar",
"digest": "sha256:bd931af693a3a815420d7bafc751f87609bb47520a8f3c2ecc5fbfc8404578ee",
"size": 10240,
"annotations": {
"org.opencontainers.image.title": "seccomp.tar"
}
}
],
"annotations": {
"org.opencontainers.image.created": "2024-02-06T08:11:44Z"
}
}Then an example image pull using libimage like this: package main
import (
"context"
"github.com/containers/common/libimage"
"github.com/containers/common/pkg/config"
"github.com/containers/storage"
)
func main() {
storeOpts, err := storage.DefaultStoreOptions()
if err != nil {
panic(err)
}
store, err := storage.GetStore(storeOpts)
if err != nil {
panic(err)
}
runtime, err := libimage.RuntimeFromStore(store, &libimage.RuntimeOptions{})
if err != nil {
panic(err)
}
_, err = runtime.Pull(context.Background(), "quay.io/saschagrunert/seccomp:v1", config.PullPolicyAlways, &libimage.PullOptions{})
if err != nil {
panic(err)
}
}Will result in: With the call stack: |
|
Yeah, but pulling that artifact into c/storage (interpreting the tarball as a container-image-like tar with whiteouts, and creating a a graph driver backing layer for the item) seems to me to be not moving us any closer to usefully consuming the artifact. Wouldn’t it be typically more useful to just refer to the included blob, and stream it as an Now, c/image probably should provide more utilities for that kind of usage (at the very least, making it easy to validate the blob digest, and very hard to forget), and the API for that doesn’t exist. |
|
How about getting a dedicated media type (echoing cri-o/cri-o#7580 (comment))? There's no actual registration cost, although I appreciate it means filling out a form and asking. |
|
Why not, but that’s not really related to the current PR’s (proposed) goal of allowing non-images to use specifically the image MIME type. If the thing in question were using any other MIME type, it would already be treated by as an artifact by c/image, regardless of the specific MIME type value. |
|
What I mean is: drop this PR, change CRI-O to expect a [new kind of] OCI object containing a seccomp profile, register a media type for that new kind of OCI object. The code in this repo need not change at all to achieve the overall outcome, which is to be able to store seccomp profiles in an OCI-compatible registry (and then specify them using URLs, in the Docker sense of URL). |
|
Yeah, I’d like that. @saschagrunert where are we on the design? My reading of cri-o/cri-o#7719 and kubernetes/website#45121 is that CRI-O is currently forging ahead with pulling the artifact into c/storage (and bypassing the need for this PR by using image-like MIME types and config contents). Are you saying that that’s the committed approach? Is the conversation of how non-image artifacts are going to be stored/pulled locally still ongoing perhaps? |
Yes the blog post on k/website represents the current implementation state in CRI-O. Having an easier way to produce those artifacts would be great. I assume having a dedicated config media type makes it more explicit, but not necessary easier to use. I'm still in favor of that and we may close this issue as already suggested.
We can still move into that direction if that's simpler, I assume it would not change anything from the consuming perspective. |
|
Proposing the change in #2306 |
@containers/image-maintainers I'm wondering if we can allow the
mediaTypeapplication/vnd.oci.empty.v1+jsonwhen parsing the OCI configs. This would make pushing OCI artifacts a bit simpler for users of ORAS, which uses this as default configuration.For example in a manifest would look like this:
{ "schemaVersion": 2, "mediaType": "application/vnd.oci.image.manifest.v1+json", "artifactType": "application/vnd.unknown.artifact.v1", "config": { "mediaType": "application/vnd.oci.empty.v1+json", "digest": "sha256:44136fa355b3678a1146ad16f7e8649e94fb4fc21fe77e8310c060f61caaff8a", "size": 2, "data": "e30=" }, "layers": [ … ],To allow this media type, we would have to mainly change the checks preventing it:
Is there a concern that this would affect all images and is this something we can generally consider?
Refers to cri-o/cri-o#7580, cri-o/cri-o#7492
The text was updated successfully, but these errors were encountered: