Handle wasm workloads as container images

[saschagrunert]

ORAS supports pushing artifacts into OCI registries, which could be used to easily distribute WASM workloads.

A few things have to be considered for that:

• ORAS per default uses the manifest.config.mediaType of application/vnd.oci.empty.v1+json, which will be treated as error in c/cimage. To avoid that, we have to select application/vnd.oci.image.config.v1+json as media type
• c/storage can only handle compressed tarballs, which means that the artifact has to be compressed before pushing

This means we can push any file like this:

# Generate a config.json to match the platform
jq --null-input '.architecture = "amd64" | .os = "linux"' > config.json

# Compress the workload
tar cfvz layer.tar run.wasm

# Push the wasm workload
oras push --config config.json:application/vnd.oci.image.config.v1+json localhost:5000/test.wasm:v1 layer.tar

# Pull the image in CRI-O's c/storage
crictl pull localhost:5000/test.wasm:v1

We now can interfere the container creation process either by image naming convention (*.wasm) or by using an additional image annotation. CRI-O can call into the WebAssembly runtime to start the workload other than using the OCI runtime.

cc @mrunalp @sohankunkerkar

[saschagrunert]

Refers to containers/buildah#5091

[jsturtevant]

The CNCF wg-wasm recently published https://tag-runtime.cncf.io/wgs/wasm/deliverables/wasm-oci-artifact/ would this be something that could be looked at as part of this work?

[saschagrunert]

The CNCF wg-wasm recently published https://tag-runtime.cncf.io/wgs/wasm/deliverables/wasm-oci-artifact/ would this be something that could be looked at as part of this work?

Yeah probably, thank you for the link!

cc @sohankunkerkar