-
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
ecds: make onConfigUpdate generic over filter type #18061
Conversation
Signed-off-by: Taylor Barrella <tabarr@google.com>
Signed-off-by: Taylor Barrella <tabarr@google.com>
/assign-from @envoyproxy/first-pass-reviewers |
@envoyproxy/first-pass-reviewers assignee is @adisuissa |
Signed-off-by: Taylor Barrella <tabarr@google.com>
Signed-off-by: Taylor Barrella <tabarr@google.com>
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.
Overall refactor LGTM, thanks!
Left a couple of comments.
/wait
const absl::optional<Envoy::Http::FilterFactoryCb> default_config = | ||
default_configuration_ ? absl::make_optional(factory_cb_(default_configuration_.value())) | ||
: absl::nullopt; |
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.
Is this default_config need to be constructed on every onConfigRemoved?
We should be able to save the factory_cb_(default_configuration_.value())
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'd prefer not to save this extra field on top of the proto just for optimization. The proto already has to be saved for applyDefaultConfiguration()
[config = default_configuration_](OptRef<ThreadLocalConfig> tls) { tls->config_ = config; }, | ||
[this, applied_on_all_threads]() { | ||
[config = default_config](OptRef<ThreadLocalConfig> tls) { tls->config_ = config; }, | ||
[this, default_config, applied_on_all_threads]() { |
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 am skeptical if the captured this
could survive when the main_callback is invoked.
Any theory to support this
will outlive?
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'm not sure, although is this out of the scope of this PR?
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 I'm skeptical too - the same thing might happen as grpc access loggers (currently being fixed).
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.
@mathetake can you share a reference here for my benefit? Thanks.
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.
#18081 and #18067 - basically I am worried about the case where DynamicFilterConfigProviderImpl has been deleted before this callback would be called on all threads. Then current_config_
(which I imagine is used in applied_on_all_threads
below) would be invalid address by the time when the callback is called.
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, this seems a plausible concern. I'm tempted to merge this though if @tbarrella wants to take this to a followup PR, since I don't see anything in this PR that makes the existing situation worse.
Signed-off-by: Taylor Barrella <tabarr@google.com>
Signed-off-by: Taylor Barrella <tabarr@google.com>
@adisuissa please let me know your thoughts on copy elision vs. |
Signed-off-by: Taylor Barrella <tabarr@google.com>
/retest |
Retrying Azure Pipelines: |
/retest |
Retrying Azure Pipelines: |
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.
Makes sense, would be good to have @kyessenov take a pass if possible as well.
/wait
[config = default_configuration_](OptRef<ThreadLocalConfig> tls) { tls->config_ = config; }, | ||
[this, applied_on_all_threads]() { | ||
[config = default_config](OptRef<ThreadLocalConfig> tls) { tls->config_ = config; }, | ||
[this, default_config, applied_on_all_threads]() { |
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.
@mathetake can you share a reference here for my benefit? Thanks.
Signed-off-by: Taylor Barrella <tabarr@google.com>
Signed-off-by: Taylor Barrella <tabarr@google.com>
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.
LGTM modulo comment thread on cleanup state; I think we can take that to a different PR.
[config = default_configuration_](OptRef<ThreadLocalConfig> tls) { tls->config_ = config; }, | ||
[this, applied_on_all_threads]() { | ||
[config = default_config](OptRef<ThreadLocalConfig> tls) { tls->config_ = config; }, | ||
[this, default_config, applied_on_all_threads]() { |
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, this seems a plausible concern. I'm tempted to merge this though if @tbarrella wants to take this to a followup PR, since I don't see anything in this PR that makes the existing situation worse.
/retest |
Retrying Azure Pipelines: |
Sorry, I was OoO but have time to review this now. |
Signed-off-by: Taylor Barrella <tabarr@google.com>
Signed-off-by: Taylor Barrella <tabarr@google.com>
Signed-off-by: Taylor Barrella <tabarr@google.com>
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.
Thanks, I think this captures and addresses by comment.
Thank you for the reviews! Anything else that needs to be done to merge? |
Sorry, @adisuissa @htuch does this look good? |
All my concerns are addressed. @adisuissa any further comments before merging? |
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.
LGTM.
* main: (221 commits) deps: Bump `protobuf` -> 3.19.0 (envoyproxy#18471) tooling: auto-assign dependency shephards (envoyproxy#18794) clang-tidy: Return from diff fun if empty diff (envoyproxy#18815) repokitteh: Block PRs pending deps approval (envoyproxy#18814) deps: Bump `org_llvm_llvm` -> 12.0.1, `com_github_wavm_wavm` -> 9ffd3e2 (envoyproxy#18747) dns resolvers: add All lookup mode (envoyproxy#18464) doc: fix link formatting for TLS session_timeout (envoyproxy#18790) ext_authz: Set response flag and code details to UAEX when denied (envoyproxy#18740) socket options: add support for directly creating ipv4/ipv6 pairs (envoyproxy#18769) ecds: make onConfigUpdate generic over filter type (envoyproxy#18061) bazel: update CMake instructions in EXTERNAL_DEPS.md (envoyproxy#18799) upstream: fix typo in comment (envoyproxy#18798) runtime: removing envoy.reloadable_features.grpc_json_transcoder_adhere_to_buffer_limits (envoyproxy#18696) bazel: Add CC=clang to clang configuration (envoyproxy#18732) fix error request id in the dubbbo local reply (envoyproxy#18741) event: assert the case of both read and closed event registered (envoyproxy#18265) tcp proxy connect tunneling: improved testing (envoyproxy#18784) deps: Bump `protoc-gen-validate` -> 0.6.2 (envoyproxy#18742) deps: Bump `rules_pkg` -> ad57589 (envoyproxy#18746) bazel: copy .bazelversion for envoy filter examples (envoyproxy#18730) ... Signed-off-by: Michael Puncel <mpuncel@squareup.com>
cc @kyessenov @lambdai
Commit Message:
ecds: make onConfigUpdate generic over filter type
Signed-off-by: Taylor Barrella tabarr@google.com
Additional Description: Part of #14696 (comment). The goal is to templatize
DynamicFilterConfigProviderImpl
while havingDynamicFilterConfigProviderImplBase
,FilterConfigProviderManagerImplBase
, andFilterConfigSubscription
agnostic to HTTP vs. network filters. This is a step in that direction, following the approach of #14717. Because extra validation was added since that PR, the filter factory object must be created beforeonConfigUpdate
in addition to duringRisk Level: Low
Testing: Existing (refactoring)
Docs Changes: N/A
Release Notes: N/A
Platform Specific Features: N/A
#14696