wasmtime 20.0.2, enabled async, networking and ip name lookup #589
Conversation
There was a problem hiding this comment.
Thanks for the for upgrade to wasmtime. I am interested in the use cases that require the additional features you've enabled. Ultimately, we might need a way customize the runtimes engines. This has come up in spinkube/containerd-shim-spin#115 as well
| @@ -29,6 +28,7 @@ impl WasiConfig for DefaultConfig { | |||
| fn new_config() -> Config { | |||
| let mut config = wasmtime::Config::new(); | |||
| config.wasm_component_model(true); // enable component linking | |||
| config.async_support(true); | |||
There was a problem hiding this comment.
What features are you looking to enable with the async support?
There was a problem hiding this comment.
I tried a sync implementation but got an error when running the demo app. If I remember correctly the error looked like this. I solved the problem by enabling async and using async linker and so on.
| .inherit_network() | ||
| .allow_tcp(true) | ||
| .allow_udp(true) | ||
| .allow_ip_name_lookup(true) |
There was a problem hiding this comment.
What's the use case you are trying to unblock?
| resource_table: ResourceTable::default(), | ||
| }; | ||
| Ok(wasi_data) | ||
| .inherit_network() |
There was a problem hiding this comment.
same here, what are the use cases?
| .allow_tcp(true) | ||
| .allow_udp(true) |
There was a problem hiding this comment.
These two are on by default, but being explicit is probably good idea.
Well, the use case that triggered these configuration sets is trivial. I'm investigating the current limits of using WASI on non-trivial "tokio-type" basic applications. I'm converting my protohackers problem solutions which are tokio based, to solutions based on WASI 0.2 components. To run the solutions I need IP name lookup, networking, tcp and udp enabled. Simple 😄 If you want to see what I'm doing on protohackers, this is my repository. Into the directory wasi there are the solutions using Rust / WASI. I have currently converted the first 4 solutions. I'll proceed with the others in the next few days. I need to implement the missing pieces in my wasi_async framework (next step: UDP). For the configurability, I'm thinking of using env vars with the WASMTIME_ or RUNWASI_ prefix, not passed to the invoked process but managed by the shim. I looked at the approach used in spim but it didn't convince me, I probably need to understand it better. |
from containerd/runwasi
|
Yeah containerd config options for the shim would be a good place to put configurations that might change the runtime behaviours. |
| ]} | ||
| wasmtime-wasi = { version = "17.0", features = ["exit"] } | ||
| wasi-common = "17.0" | ||
| wasmtime = { version = "20.0.2", features = ["async"] } |
There was a problem hiding this comment.
Wasmtime 21 was released
I saw that by updating the version the repository compiles and the tests pass. If you prefer, I open a new PR or rename this one with the transition directly to wasmtime 21
There was a problem hiding this comment.
Sure, Would you mind doing the bump to Wasmtime 21 as a separate PR? I am still not sure the implications of turning on the async support and a few of the other options enabled here. I need a little more time to understand what turning these features means. Maybe other reviewers have some thoughts too
There was a problem hiding this comment.
Sure, Would you mind doing the bump to Wasmtime 21 as a separate PR? I am still not sure the implications of turning on the async support and a few of the other options enabled here. I need a little more time to understand what turning these features means. Maybe other reviewers have some thoughts too
For the transition to wasmtime 21 in my opinion we can wait as long as, we simply need to update the dependencies of Cargo.toml.
I'm currently testing the new version on my k8s.
Please take the time to evaluate the impacts of the proposed changes. As already indicated I attempted to keep the code with async disabled but I had got failed tests so I opted to switch to async mode. This should not impact other shims.
I hope other people can try my modifications on more serious implementations than the my toy one with protohackers.
This is really cool! |
|
Need a rebase |
|
Thanks, again! @vescoc |
No description provided.