-
Notifications
You must be signed in to change notification settings - Fork 4.8k
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
ext_proc: send attributes #30781
ext_proc: send attributes #30781
Conversation
CC @envoyproxy/api-shepherds: Your approval is needed for changes made to |
Signed-off-by: Jacob Bohanon <jacob.bohanon@solo.io>
d2c1b3a
to
87cf9ba
Compare
Signed-off-by: Jacob Bohanon <jacob.bohanon@solo.io>
@tyxia @yanavlasov @yanjunxiang-google @htuch Thoughts on this? It's the same work as was previously reviewed in the linked PR #29069 |
@@ -237,7 +308,11 @@ FilterHeadersStatus Filter::decodeHeaders(RequestHeaderMap& headers, bool end_st | |||
|
|||
FilterHeadersStatus status = FilterHeadersStatus::Continue; | |||
if (decoding_state_.sendHeaders()) { | |||
status = onHeaders(decoding_state_, headers, end_stream); | |||
auto activation_ptr = Filters::Common::Expr::createActivation(decoding_state_.streamInfo(), | |||
&headers, nullptr, nullptr); |
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.
for my own education, why do we need to use CEL parser to forward the attributes? Arent these available as part of streamInfo readily? I think @tyxia 's concern was the speed and overhead when we drag the CEL parser into the picture
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.
Attributes, as documented here, are only implemented in CEL (as far as I can tell). I don't know why this very convenient mode of accessing this info was coupled to CEL in the first place, but because it is, CEL is used to access them here in lieu of re-implementing attributes in a more common/accessible location
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.
You may want to make conditional on presence of attributes in the configuration. Otherwise the CEL context is instantiated even if no attributes were needed.
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.
@yanavlasov I have made the change so the CEL context is only instantiated when needed
/lgtm api |
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.
/wait-any
@@ -237,7 +308,11 @@ FilterHeadersStatus Filter::decodeHeaders(RequestHeaderMap& headers, bool end_st | |||
|
|||
FilterHeadersStatus status = FilterHeadersStatus::Continue; | |||
if (decoding_state_.sendHeaders()) { | |||
status = onHeaders(decoding_state_, headers, end_stream); | |||
auto activation_ptr = Filters::Common::Expr::createActivation(decoding_state_.streamInfo(), | |||
&headers, nullptr, nullptr); |
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.
You may want to make conditional on presence of attributes in the configuration. Otherwise the CEL context is instantiated even if no attributes were needed.
Signed-off-by: Jacob Bohanon <jacob.bohanon@solo.io>
Signed-off-by: Jacob Bohanon <jacob.bohanon@solo.io>
Signed-off-by: Jacob Bohanon <jacob.bohanon@solo.io>
Signed-off-by: Jacob Bohanon <jacob.bohanon@solo.io>
Signed-off-by: Yanjun Xiang <yanjunxiang@google.com>
absl::flat_hash_map<std::string, Extensions::Filters::Common::Expr::ExpressionPtr> expressions; | ||
#if defined(USE_CEL_PARSER) | ||
for (const auto& matcher : matchers) { | ||
auto parse_status = google::api::expr::parser::Parse(matcher); |
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.
The CEL usage here is not correct.
We need to extend the lifetime ofparse_status
here because CEL lib specifically requires that parsed expression(return of parser::Parse() ) need to outlive the compiled expression (return ofExpr::createExpression
)
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.
According to that comment, the source_info
must also outlive the parsed expression, but we throw it away in this common method. Is this also a bug?
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.
Good observation but that is probably intentional because CHECK is not performed in Envoy:
source_info is optional for EVALUATION phase (where the return of this function is used) and is used for CHECK phase( see my comment here and working example).
So, it is fine for my CEL use case because only EVAL is performed in Envoy and both PARSE and CHECK are performed in control plane, as the split model I mentioned before. (i.e., source_info is not used)
Back to common method, I think it is fine so far and in your use case here, because CHECK has not been performed in Envoy data plane.
If we really want CHECK functionality in Envoy(probably should avoid as performance overhead), we can update that common method to use the source info in that parsed expression, i.e., return of parser::Parse(matcher)
which we want to save here.
cced @kyessenov the author of common method.
@jbohanon When you add back this PR, could we re-org the changes a bit? i.e., moving these matching related functions (that were added in this PR) to the new file/class? I think that will be cleaner and more aligned with existing structure (mutation_utils, processor_state, etc ) |
Please also re-run the below commands after re-org the changes as proposed above: If @jbohanon have problems to run the fuzzer test in your workspace, please let me know. I can run it for you. We can debug the fuzzer issues from there if it is still happening. |
I will re-org and try the fuzzer, then ping you folks on the new PR when it is up. Thanks for the attention and guidance on this! |
Introduce the ability to send attributes in the External Processing Request --------- Signed-off-by: Jacob Bohanon <jacob.bohanon@solo.io>
Introduce the ability to send attributes in the External Processing Request --------- Signed-off-by: Jacob Bohanon <jacob.bohanon@solo.io>
extract attributes changes from #29069
Commit Message:
Introduce the ability to send attributes in the External Processing Request
Additional Description:
Risk Level:
Low
Testing:
Release Notes: N/A
Platform Specific Features: N/A