OCI configuration updates to support containerd

[jsturtevant]

Based on the issue created in runwasi https://github.com/containerd/runwasi/issues/108 and the proposal to support WASI OCI artifacts in Containerd spins current OCI format won't work with out some minor modifications.

The approach outlined in the doc is to add "artifactType": "application/vnd.bytecodealliance.component.v1+wasm" and use config.mediaType as application/vnd.oci.image.config.v1+json. This allows for runtimes to still properly configure and launch the wasm applications (see https://github.com/containerd/runwasi/pull/147 as an example).

This means the current spin configuration of application/vnd.fermyon.spin.application.v1+config would need to move to be a layer in the OCI artifact and artifact type would be specified.

An example of the image manifest might look like:

regctl manifest get localhost:5000/spin:oci
Name:                                localhost:5000/spin:oci
MediaType:                           application/vnd.oci.image.manifest.v1+json
ArtifactType:                        application/vnd.bytecodealliance.module.v1+wasm
Digest:                              sha256:c74cb8cb19ee2632b4ae825c71780f48e3424cae6fc1e865cb34b1f03da35c58
Total Size:                          839.916kB

Config:
  Digest:                            sha256:30beeddd35f0d22d3c068f29fc6fb41bb9461807e427d3ebdf34d3b922704a4b
  MediaType:                         application/vnd.oci.image.config.v1+json
  Size:                              136B

Layers:

  Digest:                            sha256:499237ead273693b70fb4110b179226fe857efb6da0865fd8f8c98437f8c4467
  MediaType:                         application/vnd.bytecodealliance.wasm.component.layer.v0+wasm
  Size:                              146.992kB

  Digest:                            sha256:270f42cf04ef6dd5b5d223d14bf9a6c703f1f0df7dded6db897997006fa2ca26
  MediaType:                         application/vnd.bytecodealliance.wasm.component.layer.v0+wasm
  Size:                              692.031kB

  Digest:                            sha256:96485f14df303540d3f687be5b663a629a150c96e27697e27b4d3d75f31910b7
  MediaType:                         application/vnd.fermyon.spin.application.v1+config
  Size:                              893B

I have a prototype using this approach at https://github.com/deislabs/containerd-wasm-shims/pull/164/. Happy to answer any questions and feedback is appreciated!

[vdice]

Thanks for breaking down the updates needed for compatibility with containerd and pointing to a prototype approach @jsturtevant! We should have the flexibility to incorporate these changes; in fact, it seems we'd been waiting for an excuse to finalize media types, as you've probably noticed :)

As an aside (probably eventually best for its own issue/discussion), we also are or will be using a few more media types that I don't see used yet in the shim:

• A data media type representing static data/files used by a Spin app
• An archive media type representing a compressed archive layer (tar.gz at time of writing) of multiple data/files used by a Spin app

Is there guidance on appropriate names for these two as well?

[jsturtevant]

Right now the current thinking with the wasi component model is to package almost everything as a component. In the case of static or data files, the idea would be to create a virtual file system component that could serve those up. @devigned might have more details

[itowlson]

@vdice Would this have compatibility implications for loading already-published applications? If so, can we continue to accept the old format alongside the new one (while only publishing the new one), at least for a transitional period?

[squillace]

i have a feeling there are a lot transitory periods abounding...

[jsturtevant]

I don't see any issue with supporting both formats, It should be fairly straightforward to identify them and handle them accordingly. The only caveat is that the current format with the oci config.media type application/vnd.fermyon.spin.application.v1+config will not work in containerd with runwasi which is the current state anyways.

[vdice]

Right now the current thinking with the wasi component model is to package almost everything as a component. In the case of static or data files, the idea would be to create a virtual file system component that could serve those up.

Ah, ok - this would require a more concerted effort and non-trivial refactor for Spin to update the way it publishes (and pulls/loads) data layers. I'll bring this up with the team tomorrow. But it sounds like containerd will only be compatible with Spin apps comprised only of the config layer and one or more wasm layers? I suppose we could add support in the shim for handling other types (eg the 'data' type Spin also currently handles) -- but unneeded work if alignment/standardization on wasm-layers-only appears the best path forward.

In the meantime, we can knock out the other asks mentioned above (add spin config as add'l layer, update wasm layer and config mediaType, update artifact mediaType and artifactType).

Oh, one more question. For the artifactType metadata, the description above mentions using application/vnd.bytecodealliance.component.v1+wasm and the example shown afterwards uses application/vnd.bytecodealliance.module.v1+wasm. What are the differences and/or when are each used? Does component correspond with the WebAssemly component model and module refer more generically to any compiled WebAssembly executable?

[vdice]

@vdice Would this have compatibility implications for loading already-published applications? If so, can we continue to accept the old format alongside the new one (while only publishing the new one), at least for a transitional period?

@itowlson yes, we'll want to hash this out when we tackle this larger bit of re-work in Spin. Like @jsturtevant mentions, it sounds like support in containerd for Spin apps as currently published isn't in the cards, so compatibility concerns would only be relevant on Spin's side.

[jsturtevant]

@itowlson yes, we'll want to hash this out when we tackle this larger bit of re-work in Spin. Like @jsturtevant mentions, it sounds like support in containerd for Spin apps as currently published isn't in the cards, so compatibility concerns would only be relevant on Spin's side.

to be clear, the OCI Format today won't work in containerd but we do have spin working in with container images https://github.com/deislabs/containerd-wasm-shims/tree/main/containerd-shim-spin-v1.

What are the differences and/or when are each used? Does component correspond with the WebAssemly component model and module refer more generically to any compiled WebAssembly executable?

Yes, since component model isn't offiically out, I've been using module to make the disctinction.

I suppose we could add support in the shim for handling other types (eg the 'data' type Spin also currently handles) -- but unneeded work if alignment/standardization on wasm-layers-only appears the best path forward.

right, as it is implemented now, spin shim can handle the additional layers in any way it wants. I think long term we definitely want try to align but we are yet to see many examples of this implemented.

[jsturtevant]

@vdice @itowlson Also want to bring to your attention an issue we are discussing in OCI repository,. Some of the wording changed since I got this all working and I am attempting to make sure we still fall inside guidelines: https://github.com/opencontainers/image-spec/pull/1137

If you have any opinions on it from a WASM project perspective I think it would valuable to add your insight

[vdice]

@jsturtevant when convenient, would be great to get early feedback and confirm direction in https://github.com/fermyon/spin/pull/1882 looks good.

[vdice]

Closing per https://github.com/fermyon/spin/pull/1882. Note there may be follow-ups (eg https://github.com/fermyon/spin/issues/2000) but we can track in dedicated issues. Thanks @jsturtevant!