Open saschagrunert opened 2 weeks ago
naive question, NRI defines an API and inteface via GRPC ... does not make this agnostic of the language? Or the question is to provide a library in wasm to use NRI?
WebAssembly and gRPC clients/servers do not work well together because of API limitations: https://go.dev/blog/wasi#limitations
WASM binaries following the protobuf service definitions would work, see: https://github.com/knqyf263/go-plugin
Unfortunately, I wasn’t able to compile a plugin using the service definition from the NRI, because the API imports net/http/httptrace
and net/http/httputil
which are not compileable using tinygo (not in std). I guess that’s because of the ttrpc and therefore gRPC imports.
I could imagine that the NRI extends to binary plugins, which then opens the support for WASM.
Another limitation is that the generated code cannot be used together, see https://github.com/knqyf263/go-plugin/issues/67
Hey folks, I'm playing around with the idea of a generic CRI plugin interface for CRI-O based on WASM binaries: cri-o/cri-o#8715
A pre-compiled WASM plugin can be used to modify data before, after or even during an ongoing CRI RPC.
Would it be interesting for the NRI to support WASM as well?
Definitely ! This has come up a few times already in various discussions, but we have haven't done anything practical on this front yet.
Hey folks, I'm playing around with the idea of a generic CRI plugin interface for CRI-O based on WASM binaries: https://github.com/cri-o/cri-o/pull/8715
A pre-compiled WASM plugin can be used to modify data before, after or even during an ongoing CRI RPC.
Would it be interesting for the NRI to support WASM as well?