ext_proc: send attributes#30781
Conversation
jbohanon
requested review from
htuch,
mattklein123 and
yanavlasov
as code owners
|
CC @envoyproxy/api-shepherds: Your approval is needed for changes made to |
Signed-off-by: Jacob Bohanon <jacob.bohanon@solo.io>
jbohanon
force-pushed
the
feature/ext_proc/request-response-attributes
branch
from
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 |
| 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.
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.
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.
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.
@yanavlasov I have made the change so the CEL context is only instantiated when needed
|
/lgtm api |
| 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.
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.
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.
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.
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>
6 participants
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