Stream: WASI-Virt

Topic: Towards a more dynamic WASI-virt

Ryan Levick (rylev) (Apr 26 2024 at 14:36):

@Guy Bedford First, thanks for your work on WASI-virt, and sorry for such a long message.

tl;dr I'm going down a path that will have me rewriting basically all of WASI-virt's virtual adapter component, and I'd like to avoid that if possible. Your insight on if we could get WASI-Virt to do what I need would be super helpful.

I'm working on a testing solution for spin which does a bunch of virtualization (not only of the Spin world but of WASI imports). Right now I'm not using WASI-virt because the virtualization pattern I need differs pretty substantially from how WASI-virt works in a few ways:

• The current approach of synthesizing a component that matches statically known virtualization configuration is not what I need for spin-test. Basically all the configuration for how virtualization should happen, happens dynamically after instantiation. For example, the component which encodes all the test logic can do dynamic configuration (e.g., imagine a test which sets an environment variable before invoking the Spin app or writes the contents of a file that will be mounted into the app).
• Second, the WASI virtualization component needs imports that can be used during this dynamic configuration. In other words, the virtualization behavior will change dynamically depending on the return value of imports into the virtualization component. Specifically the virtualization component has an import get_manifest which can be used to read the spin.toml manifest (a manifest file for a Spin app) which has implications on how wasi works (such as which files are mounted).

My main concern is that WASI-virt has to jump through some interesting hoops to get static configuration working (such as allowing for its read only memory to be changed post-facto) which are all irrelevant in a world of dynamic configuration.

Question: Do you have any thoughts on how difficult it would be to change WASI-virt to allow for this use case?

Guy Bedford (Apr 29 2024 at 22:24):

I think I mostly get the use case here, and have a suggestion for how we might map that into an extension of the current WASI Virt architecture. Let me know how the following sounds or if you have further feedback and we can see if we can iterate on an approach here.

Instead of designing for an imported function, what if WASI Virt could export a dynamic configuration update function? So basically it would be a custom export, which at composition time could be configured whether or not it should be exposed to the top-level component exports of the component being virtualized.

Then, this function could take the full configuration scheme for WASI Virt, and update in place its internal static configuration to reflect the dynamic configuration update.

The hard part here mostly seems to be the composition story, but perhaps there's a simple way we could define that when you do a composition of a component with a virtualization, this function could somehow be specially marked in that composition to be directly merged and exposed instead of satisfying the component imports.

Does something like that sound like it would be able to be used for your use case?

Last updated: Nov 22 2024 at 16:03 UTC