question: detecting which `.wasm` to load and run? about containerd-wasm-shims HOT 4 OPEN

Glad you brought this up. @Mossaka and I were just talking about this. Right now, I believe the runtime expects an /app.wasm, as you say, it should be in the configuration or the entrypoint.

I'd like to see us move the slightfile out of the image and mount that as part of the pod spec. I think we are only adding it to the image at this point for simplicity.

We need to be much more precise in the "spec" for fs layout (definitely heavy quotes).

from containerd-wasm-shims.

We'd like this to work with a single container for now, because it's easy and as there's a "shim per host model" each shim needs to know how to map the artifacts for that model. Well heck, that's not very "speccy". :-)

Note that David says

I'd like to see us move the slightfile out of the image and mount that as part of the pod spec. I think we are only adding it to the image at this point for simplicity.

I'm of two minds about this, so it's the kind of thing we'll iterate on with users and anyone else who wants to work with this approach.

On the one hand, using a container/graph to deploy the topology of the host model in one swoop means that you can deploy that host model singly -- as in fire-and-forget edge functions, for example -- and deploy precisely the same thing without any modification in a container/graph to k8s. This, mind you, so long as the shim is in sync with that version of the host model, right?

Upside: k8s is now very clean manifest/chart, workload is treated as an immutable unit, making deployments far, far easier for pretty much everyone, both dev and deployer alike.
Downside: It is now denying the pure k8s experience, in which the topology of a host model is ripped apart and config must migrate to volumes or configmaps and so on but brings with it the visibility of operations that a k8s operator would really like.

the oddness is that I could see enabling both approaches as well. It may be that small clusters in constrained, heterogeneous environments -- single node clusters on risc-v SoCs for example -- might well want a topology stamp. No operator is going to really want a bunch of separate things there; it's too much and those clusters will not have ongoing management. (If they're attached to an edge cluster management service, there's every chance that touching thousands or millions of those clusters is, while theoretically possible, realistically a mess to avoid.)

We'll have our thoughts here, but I'm happy to take ideas!

from containerd-wasm-shims.

how the shims know to look for spin.toml in the image layer contents, and not credenza.toml or pteradactyl.toml. If I had all three, would only spin.toml be read by convention?

The spin shim has a convention to look for the spin.toml file in the root directory (rootfs). Yes you're right, if you have all three toml files, it would only read spin.toml by convention.

The slight shim, however, has a different convention for now. It reads slightfile.toml and app.wasm in the rootfs directory.

If you'd like to see how they are implemented, the relevent lines are here for spin shim and slight shim, resp:
https://github.com/deislabs/containerd-wasm-shims/blob/main/containerd-shim-spin-v1/src/main.rs#L49
https://github.com/deislabs/containerd-wasm-shims/blob/main/containerd-shim-slight-v1/src/main.rs#L64-L65

Can an Image/Artifact used by these shims contain multiple [[component]]s, and therefore multiple .wasm files?

The spin shim can, because all the paths to wasm modules are defined in a single spin.toml manifest file. The slight shim currently does only work for one wasm module named app.wasm.

from containerd-wasm-shims.

Noted: this means that there must always be a mapping between shim and host model version as well. For now that's fine, as we move forward something a tad more "structured" should probably exist.

from containerd-wasm-shims.