-
Notifications
You must be signed in to change notification settings - Fork 88
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Where do we define the Wasm "container" boundry #619
Comments
some further conversation and context in https://cloud-native.slack.com/archives/C06PC7JA1EE/p1717097248450109 |
Let me clarify why we are seeing "if a user is using a Rust wasm application and they set RUST_LOG on their podspec, then it will switch logging for everything in There are two shim processes when started:
When the child shim process invokes youki's This happens prior to Back to your question: "where the boundary should live for the shim vs wasm?". I think from the user's perspective, they would have assumed that their application environment variables (i.e. from PodSpec) should only be seen by their application (i.e. WASI environment consumed by Wasm modules). The next question is how do we achieve that? I am thinking about either
|
I am concerned about these options. If we do not allow for configuring the Wasm runtime/Spin engine via container env vars, how will we do app level execution configuration? For example, how do we configure which port for a Spin app to listen on? I'd prefer to continue to set these env vars on the Wasm runtime and tell the users a user story wherein for Wasm, the container env vars configure the Wasm runtime, especially given that Spin apps often contain multiple Wasm instances. Would setting container env vars mean setting those env vars in each instance's environment? This is part of the reason Spin encourages using configuration variables over environment variables. I do understand that it is a different user story than that of containers. If there is a way we can configure the Spin runtime and Spin app env vars at a container level that would be a double win. |
right now, spin doesn't use the env's in the same way as wasmtime shim, so each instance only gets the the values in spin-toml as defined in https://developer.fermyon.com/spin/v2/variables I think one of the challenges is there is a additional component in scope compared to the traditional container environment. One of the goals of runwasi is wrap the wasm execution in a "container" to provide additional security and smoother transition coming from the expectations of using containers. The additional component comes from the fact that wasm has two parts: a host (spin or wasmtime) and guest (wasm binary). They both have unique configuration values beyond the container. With our current set up we run both in the "container" which means from an OCI perspective we don't really have the ability to distinguish between the two. Should the host run inside the context of the container? I believe it should. A concrete example is given by @kate-goldenring : the host needs to know the ip and port to bind to. How do we distinguish between host configuration and wasm configuration? After reading up on Spins approach to configuration. I am under the impression that we are not doing the right thing with the wasmtime shim:
I am still unsure the correct solution across all shims... Maybe it is unique choice for each shim? |
Spin does also support environment variables. Similar to We could also support the |
The ideas are great, I agree it does come down to the shim (but maybe there is opportunity for Wasm and/or OCI to provide a way to standardize this longer term) and I also don't want to drop support the envs fully from wasmtime shim. Having it be a unique choice for each shim, seems like a good approach for now. |
@jsturtevant @Mossaka @devigned @cpuguy83 in our runwasi meeting this morning, we discussed this more synchronously, settling on a potential approach of setting all container env vars as application variables in the Spin shim. After some thinking, i found a caveat to this approach: this only works if you use the environment variable provider for application variables, which can also be set through other providers such as Azure Key Vault or Vault. This is because Spin currently only supports one application provider per app. In our discussion on the sandbox API, @devigned pointed out that in general we should take the approach that is the most container-like to users. On that note, how do we handle injection of cluster information environment variables such as
[[EDIT]]: Spin already supports multiple variables providers. |
\o/ for multiple variable providers! |
I believe #668 has resolvevd the biggest concern of this issue - the concern for environment variables and configuration. |
We are doing a bunch of set up work for the wasm runtime inside the container and using rust log crate. We are effectively still operating as the "shim" until we invoke the Wasm binary for example
runwasi/crates/containerd-shim-wasmtime/src/instance.rs
Line 163 in 7cc5e5a
This leads to some confusion from an end user perspective in some scenarios. For instance if a user is using a Rust wasm application and they set
RUST_LOG
on their podspec, then it will switch logging for everything inrunwasi/crates/containerd-shim-wasm/src/container/engine.rs
Line 16 in 7cc5e5a
This could also happen when we start to enable tracing in #582
Since there is some additional set up of the wasm runtime, this leads an issue of where the boundary should live for the container vs wasm.
The text was updated successfully, but these errors were encountered: