Stream: rfc-notifications

Topic: rfcs / PR #40 add Wasmtime RPC RFC

RFC notifications bot (Nov 01 2024 at 13:51):

rvolosatovs opened PR #40 from rvolosatovs:wasmtime-rpc to bytecodealliance:main:

Refs https://github.com/bytecodealliance/wasmtime/issues/7348
Refs #39

Rendered

RFC notifications bot (Nov 01 2024 at 13:52):

rvolosatovs edited PR #40:

Refs https://github.com/bytecodealliance/wasmtime/issues/7348
Refs https://github.com/bytecodealliance/rfcs/pull/39#issuecomment-2451907457

Rendered

RFC notifications bot (Nov 01 2024 at 13:52):

rvolosatovs edited PR #40:

Refs https://github.com/bytecodealliance/wasmtime/issues/7348
Refs https://github.com/bytecodealliance/rfcs/pull/39#issuecomment-2451907457

Rendered

RFC notifications bot (Nov 01 2024 at 13:58):

bjorn3 submitted PR review.

RFC notifications bot (Nov 01 2024 at 13:58):

bjorn3 created PR review comment:

It seems like this wouldn't allow using multiple plugins at the same time. Only a single plugin exposing multiple interfaces. Maybe a syntax like -P import=wasi:keyvalue=wrpc+tcp://[::1]:7761 -P import=wasi:nn=wrpc+unix://run/user/1000/wasi_nn.sock would work?

RFC notifications bot (Nov 01 2024 at 14:00):

bjorn3 submitted PR review.

RFC notifications bot (Nov 01 2024 at 14:00):

bjorn3 created PR review comment:

If a default port is used, should it be registered with IANA? And what should the default be for unix domain sockets? /run/user/<uid>/<package_name>.sock?

RFC notifications bot (Nov 01 2024 at 14:02):

bjorn3 submitted PR review.

RFC notifications bot (Nov 01 2024 at 14:02):

bjorn3 created PR review comment:

How is authentication handled? Would it require a CA certificate or are self-signed certificates allowed?

RFC notifications bot (Nov 01 2024 at 14:03):

bjorn3 submitted PR review.

RFC notifications bot (Nov 01 2024 at 14:03):

bjorn3 created PR review comment:

The only option that would allow backward compatibility on the Wasmtime side I think would be to make plugins shadow builtin implementations.

RFC notifications bot (Nov 01 2024 at 14:08):

rvolosatovs created PR review comment:

Definitely open to suggestions here, I struggled to come up with a design, which would not feel overloaded and as I mention in the open questions section. I've decided to start with a singleton plugin because of the CLI design concerns and the fact that shared state (e.g. resources) gets increasingly more tricky as number of plugins grows.

Perhaps we would just need to come up with wasmtime.toml-or-similar config file eventually, which would define the mapping, since mapping every single interface to an endpoint on the CLI feels quite tedious if the number of interfaces is large.
That's probably not much worse than the likes of docker run -v$path:$path -w$path, so perhaps endpoint per-interface is fine at least to start with

RFC notifications bot (Nov 01 2024 at 14:08):

rvolosatovs submitted PR review.

RFC notifications bot (Nov 01 2024 at 14:19):

rvolosatovs submitted PR review.

RFC notifications bot (Nov 01 2024 at 14:19):

rvolosatovs created PR review comment:

I chose 7761 pretty arbitrarily, if this RFC is accepted and we're happy with this number, IANA registration sounds like the right thing to pursue.

In terms of the UDS path I guess we'd need to first determine if we want plugins to be composable or if we want it to be a singleton. If we go the multiple-plugins route:

$os-specific-runtime-dir/wrpc/wasi/$name.sock

e.g.

/run/user/$uid/wrpc/wasi/http.sock
/run/user/$uid/wrpc/wasi/keyvalue.sock
/run/user/$uid/wrpc/myorg/mypackage.sock

seems like a reasonable default for wRPC-based plugins on UDS.

RFC notifications bot (Nov 01 2024 at 14:27):

rvolosatovs submitted PR review.

RFC notifications bot (Nov 01 2024 at 14:27):

rvolosatovs created PR review comment:

Depends on the implementation, ultimately wasmtime CLI user would be the one to decide, one thing to note though is that in current implementation, SAN is (ab?)used to specify the function being called: https://github.com/bytecodealliance/wrpc/blob/628e6bf79416ca2671d0a3c79ac25949f9bf84d8/crates/transport-quic/src/lib.rs#L29-L42

Currently, self-signed or not, the server (plugin) needs to generate a cert with appropriate SANs.

This can easily be changed/made configurable to e.g. be specified in the stream header as done for e.g. TCP and UDS https://github.com/bytecodealliance/wrpc/blob/628e6bf79416ca2671d0a3c79ac25949f9bf84d8/crates/transport/src/frame/conn/client.rs#L33-L43
I feel like being able to sign served plugin capabilities may come in quite handy, but I don't have strong feelings about this

RFC notifications bot (Nov 01 2024 at 14:28):

rvolosatovs edited PR review comment.

RFC notifications bot (Nov 01 2024 at 14:29):

rvolosatovs edited PR review comment.

RFC notifications bot (Nov 01 2024 at 19:10):

rvolosatovs edited PR review comment.

Last updated: Dec 23 2024 at 12:05 UTC