Enable WasmEdge roofs support and start writing OCI tests for Wasmedge and Wasmtime #111
Conversation
ipuustin
changed the title
ipuustin
changed the title
There was a problem hiding this comment.
Thanks for contributing more tests for OCI!
I quickly skimmed through the test cases and noticed that the larger part of them are not Wasmedge specific - which means the same set of tests can be port to test the wasmtime shim as well.
After #142 is merged upstream, I am happy to take this task of making these tests available across shims.
Thanks! In fact the Wasmtime support is already present in the tests but commented out, because the OCI support is not there yet. If you like, you can try rebasing #142 on top of this PR, removing the comments (marked with |
There was a problem hiding this comment.
This is a great, It feels like you're on the verge of creating a framework for testing different module specs. I've made one suggestion to leverage our Instance trait and invert the logic a bit that would make it so we could easily re-use the tests across different runtimes. Let me know if that makes sense
test/oci-tests/tests/common/mod.rs
Outdated
| .set_bundle(dir.path().to_str().unwrap().to_string()) | ||
| .set_stdout(dir.path().join("stdout").to_str().unwrap().to_string()); | ||
|
|
||
| let wasi = Arc::new(WasmEdgeWasi::new("test".to_string(), Some(cfg))); |
There was a problem hiding this comment.
I believe this returns the trait Instance? If so we could invert this. Create the config and the instance outside the module and make this function generic run_test_with_spec and pass in the module.
This would make the tests written below to not be specific calls to each runtime let (output, retval) = common::run_wasmedge_test(&spec, &bytes)?; making it more of a framework.
| @@ -62,6 +62,10 @@ jobs: | |||
| args: --all --verbose | |||
| - name: Validate docs | |||
| run: ./scripts/validate-docs.sh | |||
| - name: Setup rust-wasm target and compile test modules | |||
| run: | | |||
| rustup target add wasm32-wasi | |||
There was a problem hiding this comment.
if you put this in the make target it makes, it will just skip if already present and makes it so some one runs that step they don't miss it
|
Is this PR ready for review? @ipuustin |
It will be shortly -- I'll still add the Wasmtime OCI tests, because the support should be there now with the libcontainer integration. |
ipuustin
changed the title
The first such moduels are a test to enumerate default devices in the container and a hello world application, which also gets the current working directory. This can be used to test seccomp filter. Signed-off-by: Ismo Puustinen <ismo.puustinen@intel.com>
Signed-off-by: Ismo Puustinen <ismo.puustinen@intel.com>
Enable WasmEdge modules to access the container filesystem. This includes: * all the files on the container image * /proc filesystem * /sys filesysten * parts of /dev filesystem Signed-off-by: Ismo Puustinen <ismo.puustinen@intel.com>
|
One missing part is that we now need to have a direct dependency to Wasmtime and WasmEdge crates to have access to the engine/Vm object. If we go this way, we probably should have Wasmtime and WasmEdge dependency in the workspace. |
Now that we have support for OCI runtime spec for Wasmedge shim, we should try to do two things:
Those OCI spec features which don't really map to Wasm modules we can try to test on the runtime level, checking for example which capabilities the runtime process has?
This PR adds an external directory for storing/building the Wasm modules and an integration test directory for Wasmedge shim for trying out the OCI spec features. I added some seccomp and device file tests for seeing how this would work in practice. Support for Wasmtime is commented out because the OCI support (#142) hasn't been merged yet, but could be useful in testing the PR.
So, I think the first question is: which OCI features are meaningful and should be tested for Wasm/WASI containers? For example it could be argued that the Wasm modules should never see the device files, but the Wasm runtimes should, so that they could expose the features through the WASI APIs. The second question is that is this approach of having the test Wasm modules in-tree the right way forward? The problem is that it appears to be difficult or impossible to run
cargo buildfor two architectures at the same time (making the tests depend on the Wasm module build).