Deploy from an OCI reference

[itowlson]

This is VERY VERY DRAFT. The code needs a lot of tidying ; it doesn't currently validate OCI apps (for unsatisfied variables, nondefault stores, etc.); and I have broken the route printing. And probably other stuff too. But it worked, on my machine, at least once, so

NOTES:

• The download from the source registry currently always requires HTTPS and uses the default Spin cache. We could add deploy options for these if we wanted to - easy to implement, but more for users to understand.

[itowlson]

The Spin crates are pointed to my fork because this depends on fermyon/spin#1825 - I couldn't see a way around needing this extra API, but I'm happy to take one if someone points out the blindingly obvious one I utterly missed.

[itowlson]

I believe this is ready for review, but am leaving as draft because the Cargo.toml Spin crate references can't be finalised until fermyon/spin#1825 merges.

[itowlson]

The required Spin change is merged: the Spin references now point to the main repo. Ready for review.

[kate-goldenring]

For OCI deploys, do we need a "validate wasm" step? I can see a concern of a malicious wasm module being deployed in an OCI reference. Maybe we run the equivalent of wasm-tools component wit to ensure that the Spin app has the imports and exports that we expect?

[itowlson]

Good question. We don't currently do that for other Wasm files, e.g. those from URLs. How would you feel about punting that to a separate PR, possibly somewhere in the loader so it would work for local Spin too?

[fibonacci1729]

There is also the wasm-tools component targets ... command to ensure a component has the proper type. The diagnostics on error to explain the difference between actual and expected are pretty gnarly ATM but...

[kate-goldenring]

@itowlson I am okay with punting to another PR. On that note, @fibonacci1729 is this work planned for spin as part of the broader validation efforts? Maybe we create an issue to track it and potentially take this portion of it on soon

[vdice]

This looks great! Only had non-blocking Qs/thoughts.

Will we want to add the same reference -f support to spin registry push at some point?

[itowlson]

@vdice Sorry, I overlooked your question:

Will we want to add the same reference -f support to spin registry push at some point?

spin registry push already supports -f for local applications. Are you envisaging a scenario where we could use it to copy an image from one registry to another?

[vdice]

Are you envisaging a scenario where we could use it to copy an image from one registry to another?

Yes, that was my thought. Not sure if a priority to support. Honestly, I was more thinking about consistency of -f supporting both local manifest and oci ref between related commands.