-
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: removed automatical route refreshment and add a foreign function to clear the route cache #36671
wasm: removed automatical route refreshment and add a foreign function to clear the route cache #36671
Changes from all commits
de74d9f
b8c210c
dad1f7b
8080459
5c80bc7
27830ab
13e26ea
1f78fad
1da41e1
8f5eafa
ead4115
87a3a55
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -126,6 +126,14 @@ RegisterForeignFunction registerSetEnvoyFilterStateForeignFunction( | |
return WasmResult::BadArgument; | ||
}); | ||
|
||
RegisterForeignFunction registerClearRouteCacheForeignFunction( | ||
"clear_route_cache", | ||
[](WasmBase&, std::string_view, const std::function<void*(size_t size)>&) -> WasmResult { | ||
auto context = static_cast<Context*>(proxy_wasm::current_context_); | ||
context->clearRouteCache(); | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. nit: Is this safe to call at any point in execution? This is untrusted code calling out, we might need to harden it if it's not already done. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I remember I did check in the clearRouteCache self. Will re-check it again. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. The clearRouteCache will be forbided after the response headers is processed. But I agree we should harden it continuously to ensure the interface that's provided to extension is robust enough. For example, only allow the head filter to clear the route cache. I will do this with another PR. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I think from the separate discussion in proxy-wasm-spec, what we need is a control knob on the filter xDS with several options:
We can split this into several booleans as well (e.g. 3 - could be a separate knob). There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Now, this PR removed the automatic route refresh and provide a manual way. This should be good enough as a default way to handle the route cache. New options (3 and 4) could be treated as independent requirement of Envoy-self and be implemented in the future. I think a basic rule is There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. @kyessenov yeah, that sounds good, although I'm not sure I understand the difference between 1 and 4. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
seems I didn't got it correctly. 😞 There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. @PiotrSikora The difference is that 1) clears route only on header operations but 4) should clear routes on any dynamic metadata or other non-HTTP attribute update |
||
return WasmResult::Ok; | ||
}); | ||
|
||
#if defined(WASM_USE_CEL_PARSER) | ||
class ExpressionFactory : public Logger::Loggable<Logger::Id::wasm> { | ||
protected: | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I believe this is available via
wasm()->abiVersion()
in the callbacks, so you shouldn't need to retain it.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, you are completely right at the production code view. But this is helpful for our tests now to allow us to mock different abi versions.
Our tests also need to be improved to avoid this, but, I want to put this to a refactoring only PR, for our tests/Plugin class/Wasm class etc.
(Much things need to do... :(
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
(optional) WDYT about instead defining a virtual Context::getAbiVersion() method whose default impl calls wasm()->abiVersion(), but can be overridden by TestContext?
The minor quibble I have with adding an abi_version_ field here is that now the information is stored in multiple places, as opposed to one authoritative source.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
SGTM. But I want to did some refactoring to these code anyway, will defer this to future PR.