-
Notifications
You must be signed in to change notification settings - Fork 4.9k
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
wasm: expose env variables to Wasm VMs through environ_get WASI interface #14958
Labels
area/wasm
design proposal
Needs design doc/proposal before implementation
enhancement
Feature requests. Not bugs or questions.
Comments
mathetake
added
enhancement
Feature requests. Not bugs or questions.
triage
Issue requires triage
labels
Feb 5, 2021
This was referenced Feb 5, 2021
antoniovicente
added
the
design proposal
Needs design doc/proposal before implementation
label
Feb 8, 2021
Do you have a specific proposal in mind? cc'ing other folks involved in WASM integration. |
This is already part of WASI spec (see discussion in proxy-wasm/spec#19). The only missing piece is Envoy implementation and exposing it in the configuration. |
What are the next steps?
|
Consensus has been reached. @mathetake is already working on it proxy-wasm/proxy-wasm-cpp-host#126. |
htuch
pushed a commit
that referenced
this issue
Mar 8, 2021
This commit adds an API on VmConfig so that users can configure env vars to be injected to Wasm VMs. Resolves #14958 Signed-off-by: Takeshi Yoneda <takeshi@tetrate.io>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
area/wasm
design proposal
Needs design doc/proposal before implementation
enhancement
Feature requests. Not bugs or questions.
Reading env variables from inside Wasm VMs are already defined in WASI's environ_get functions, and well supported in various compiler toolchains. However the current implementation of proxy-wasm-cpp-host and envoy does not expose any value to a VM.
There are strong demands from the community for supporting this, and it makes sense to add the new configuration in the Wasm filter's extension to control which variables should be exposed to the Wasm VM.
ref: proxy-wasm/spec#19
The text was updated successfully, but these errors were encountered: