Closed phlax closed 1 year ago
[2023-05-31 10:21:05.114][18][error][wasm] [external/envoy/source/extensions/common/wasm/wasm_vm.cc:38] Failed to load Wasm module due to a missing import: env�.proxy_get_header_map_valuen
This is because WAMR was updated here, but apparently not in Envoy, and they made a breaking changes in the code.
You need to update WAMR (and presumably LLVM) in Envoy first, unfortunately.
You need to update WAMR (and presumably LLVM) in Envoy first, unfortunately.
im trying to knock out a set of patch releases (hopefully tomorrow) to address any flagged cves, so trying to push this through
ill raise a pr to update wamr now ...
versions updated here - this really needs a better solution for updating
confirming that this PR at current HEAD + wamr update passes envoy ci
versions updated here - this really needs a better solution for updating
IMHO, the best way would be if Envoy used proxy_wasm_cpp_host_repositories()
and proxy_wasm_cpp_host_dependencies()
to pull required deps instead of redeclaring them in Envoy.
But I think there was a supply chain related reason why you want to control them there?
... the best way would be if Envoy used ...
how would that be different if one of us still has to come here and do this to update?
the only difference i think would be that we would probably not actually see the CVE notices
updated to 9.0.3
updated to 9.0.3
somewhat involuntarily - it changed all the versions running generate-lock - ie didnt respect the various places the versions are (manually) set
how would that be different if one of us still has to come here and do this to update?
the only difference i think would be that we would probably not actually see the CVE notices
You'd only need to do a single "atomic" bump of proxy-wasm-cpp-host
in Envoy, without risk of having other dependencies out-of-sync, like with WAMR now (I thought that was your main complaint?).
You'd only need to do a single "atomic" bump of proxy-wasm-cpp-host in Envoy, without risk of having other dependencies out-of-sync, like with WAMR now
i guess there is some benefit to delegating the dep setup - it would mess up our cve tracking, which tbh, i think this repo depends on as we are the ones updating it
(I thought that was your main complaint?).
the main complaint is the complexity of doing this - everyone dreads it and as we track the cves it needs to be updated fairly frequently
ideally we reduce what is required to a single command - ie ./ci/update_wasmtime.sh
kinda thing - then it would be no big deal, and potentially could be automated with ci here - the current situation is a nightmare
the main complaint is the complexity of doing this - everyone dreads it and as we track the cves it needs to be updated fairly frequently
ideally we reduce what is required to a single command - ie
./ci/update_wasmtime.sh
kinda thing - then it would be no big deal, and potentially could be automated with ci here - the current situation is a nightmare
cc @mpwarres @martijneken
@PiotrSikora this seems to be passing ci here, but when i test it in envoy ci im seeing errors like ...
https://dev.azure.com/cncf/envoy/_build/results?buildId=138916&view=logs&j=e969334a-0e55-5c18-ac96-8b546753391e&t=32392586-69f5-5768-4caa-e00e8d4cc47e&l=407