Stream: git-wasmtime

Topic: wasmtime / issue #8086 Change `wasmtime serve` to apply `...

Wasmtime GitHub notifications bot (Mar 12 2024 at 12:07):

tschneidereit opened issue #8086:

People keep running into problems with wasmtime serve because by default it only exposes wasi:proxy, nothing else. I think we should change the behavior here to imply -S common to make default toolchains and in particular the normal Preview1 adapter work.

One could see it as a downside that wasmtime serve would be a bit less specifically about HTTP, but I can't really come up with compelling arguments for why that'd be a problem.

Wasmtime GitHub notifications bot (Mar 12 2024 at 15:56):

alexcrichton commented on issue #8086:

The reason this wasn't done by default originally was because it was seen as desirable to have wasmtime serve by-default work with the wasi:http/proxy world. By enabling -S common by default it means that, I suspect, no provider works with wasi:http/proxy by default.

Given that I'd personally see two possible routes from here:

1. Improve tooling/errors/etc to better guide developers towards success through the proxy adapter. Unsure what this would mean for various tools and such, but there's probably at least something to improve here.
2. See this as rationale and pushback for having such a small wasi:http/proxy world and add more imports there (e.g. -S common)

If possible I think it'd be good to hold the line where wasmtime serve matches wasi:http/proxy by default and the problems with the adapter serve as motivation for rejiggering something else in the system. (although I'm not necessarily 100% opposed to just turning on -S common, I mostly think it'd be good to try to keep this line if we can, but not at all costs)

Wasmtime GitHub notifications bot (Mar 13 2024 at 12:55):

tschneidereit commented on issue #8086:

I agree that in principle it'd be good to keep this minimal. I'm not convinced that we'll be able to provide a developer experience here that'll not have people continue to run into roadblocks immediately. Yes, we can make those roadblocks easier to understand (and should, independently, of this particular issue!)

I think there are two things making this challenging to address: one is that perhaps the reality is that most use cases really do want more of WASI for running a server than is currently contained in wasi:http/proxy. The other though is that most tooling still uses the WASIp1 adapter, and that that adapter just pulls in more requirements than we provide. If there's a way to address the latter somehow, that'd go a long way to a solution. I do not think that forcing people to understand the concept of adapters and making them choose between multiple is a good answer, fwiw.

If we can't solve this, then that to me indicates that we should make wasmtime serve work with the adapter out of the box, independently from our stance on what should and shouldn't be in wasi:http/proxy.

Wasmtime GitHub notifications bot (Mar 13 2024 at 17:30):

alexcrichton commented on issue #8086:

To clarify though I'm not arguing for minimality, I agree that we should turn -S common on by default. This was discussed a bit while ago as well for some added context.

My point is that adding -S common by default is, in my opinion, not the best place to fix this. If we did that I think it's admitting that when facing reality the proxy world is too small, and I'd prefer if the wasi:http/proxy world itself admitted to said reality and added more interfaces.

Or perhaps put another way, can you expand a bit more on why you think it's ok wasmtime serve and wasi:http/proxy diverge? That's what I'm trying to keep aligned, but it sounds like you think it's ok if they diverge.

Wasmtime GitHub notifications bot (Mar 14 2024 at 11:07):

tschneidereit commented on issue #8086:

Or perhaps put another way, can you expand a bit more on why you think it's ok wasmtime serve and wasi:http/proxy diverge? That's what I'm trying to keep aligned, but it sounds like you think it's ok if they diverge.

Yeah, that is a great question, and I agree that it needs an answer if we want to change anything here (that doesn't involve changes to wasi:http/proxy.

My take is twofold: one part is very pragmatically that, as mentioned above, it's very difficult right now to target a pure wasi:http/proxy environment. If we can truly address that in a reasonable timeframe, I'm all for it. I don't really know what that'd look like, though.

The second part is that serve indicates something more than proxy does. In fact, I think we should also add the ability to map directories to preopens, as for wasmtime run.

I guess more generally I'm in this case not too concerned about the availability of more functionality leading developers to expect those to be available in all environments implementing wasi:http/proxy. That's an argument based on intuition of course, so it might well be wrong.

Wasmtime GitHub notifications bot (Mar 14 2024 at 18:24):

alexcrichton commented on issue #8086:

Reading over https://github.com/WebAssembly/wasi-http/issues/79 again I think I'm probably the only one advocating for wasi:http/proxy and wasmtime serve being the same thing, and I additionally don't disagree with anything you say. I'll send a PR to update this.

Wasmtime GitHub notifications bot (Mar 18 2024 at 15:09):

sunfishcode commented on issue #8086:

Thinking about this more, it seems desirable to avoid a situation where filesystems/sockets come to be seen as "common" functionality that's implicitly included in everything.

One potential problem here is that -S common is confusingly named. My understanding is that the name "common" came from "wasi-common" which came from having code in common between wasmtime and lucet. But it sounds like "common functionality". I've now submitted https://github.com/bytecodealliance/wasmtime/pull/8166 to rename it.

Another potential problem is that -S common might be too coarse-grained. Perhaps we should split it up so that users that just need environment variables don't need to pull in the rest.

Even with the rename, and even if we provide finer-grained flags, there still a question of, what do we want the proxy world to be? And, if we start bundling files/sockets/etc. with it by default, will it be harder in the future t disable it by default again, if we improve the ergonomics and want to start promoting platforms based on the proxy world?

What if we added a diagnostic to wasmtime for when a program has unsatisfied imports that suggests users add -S flags that would satisfy their imports? Would that be enough, to justify keeping wasmtime serve the same as wasi:http/proxy? There'd still be a papercut when users get the error, and have to add the flag. But at least it'd be clear to users what they need to do.

Wasmtime GitHub notifications bot (Mar 18 2024 at 16:27):

tschneidereit commented on issue #8086:

What if we added a diagnostic to wasmtime for when a program has unsatisfied imports that suggests users add -S flags that would satisfy their imports? Would that be enough, to justify keeping wasmtime serve the same as wasi:http/proxy? There'd still be a papercut when users get the error, and have to add the flag. But at least it'd be clear to users what they need to do.

I think having that would to some degree alleviate my concerns here. I'm not sure it would have all that much value though: I'm skeptical that users would take much more away from this than "oh ok, I guess the way to run these things in the Wasmtime CLI involves adding -S [something].

I also don't really think that wasmtime serve is the right place to teach people to target wasi:http/proxy: there are lots of use cases for running a server that have nothing to do with an L7 proxy.

Wasmtime GitHub notifications bot (Mar 19 2024 at 17:46):

sunfishcode commented on issue #8086:

For example, on crates.io dependencies can include their own wit-bindgen bindings, which then get silently added to the implied world of the final component. It's possible for developers to pick up additional component-model-level dependencies without being aware of it.

If we want to have small and simple works like wasi-http's proxy, but also things like wasi-cloud-core's http-service and more, and not have filesystems and sockets and environment variables become de-facto dependencies in all the places, where's the time and place to push back?

Last updated: Nov 22 2024 at 16:03 UTC