-
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
http filter: Add overrideable function to http filter factory interface for specifying FilterDependencies #15157
Conversation
Signed-off-by: Auni Ahsan <[email protected]>
Signed-off-by: Auni Ahsan <[email protected]>
@htuch would it make sense to land chunk by itself? If so, could you help me find a reviewer to tag? |
Signed-off-by: Auni Ahsan <[email 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.
@snowp since this filter chain validation work overlaps the filter match work you are involved with, would you be willing to be a non-Googler senior maintainer to shepherd these PRs?
@@ -93,6 +93,7 @@ New Features | |||
* http: added support for `Envoy::ScopeTrackedObject` for HTTP/1 and HTTP/2 dispatching. Crashes while inside the dispatching loop should dump debug information. | |||
* http: added support for :ref:`preconnecting <envoy_v3_api_msg_config.cluster.v3.Cluster.PreconnectPolicy>`. Preconnecting is off by default, but recommended for clusters serving latency-sensitive traffic, especially if using HTTP/1.1. | |||
* http: change frame flood and abuse checks to the upstream HTTP/2 codec to ON by default. It can be disabled by setting the `envoy.reloadable_features.upstream_http2_flood_checks` runtime key to false. | |||
* http filter: add function to `NamedHttpFilterConfigFactory` which can be overridden to return a :ref`FilterDependencies <envoy_api_file_envoy/extensions/filters/common/dependency/v3/dependency.proto>` specification. Config-plane validation of dependencies is currently WIP. |
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 think you can skip this for now, since its very internally focused. I'd add a single release note when we have the filter chain deps validation working.
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.
Sounds good.
include/envoy/server/filter_config.h
Outdated
* @return FilterDependencies specification of dependencies required or | ||
* provided on the decode and encode paths. | ||
*/ | ||
virtual envoy::extensions::filters::common::dependency::v3::FilterDependencies dependencies() { |
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.
Nit: probably const&
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.
filter_config.h:212:12: error: reference to stack memory associated with local variable 'dependency' returned [-Werror,-Wreturn-stack-address]
return dependency;
I could try declaring a static helper function to return it? But I imagine this will cause problems for overriders of this function anyway, who will have to construct the proto somehow.
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.
Oh, I see what's going on. This is more similar I think to createEmptyRouteConfigProto()
above. I think you should return a unique_ptr
with the allocated dependencies in this case.
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 don't understand what the value of that would be; the dependency specification protos won't typically be very large, so passing it by copy seems ok to me. What do you think?
@snowp in case you have any thoughts
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.
With the protos being small I don't think it matters a whole lot, but a unique_ptr might better future proof this in case this changes? I can imagine some filter potentially providing a lot of different dependencies even if none do so today
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.
Right, the protos contain multiple strings and we try not copy them around in general.
This reverts commit ec1d1e4. Signed-off-by: Auni Ahsan <[email protected]>
Signed-off-by: Auni Ahsan <[email protected]>
/retest |
Retrying Azure Pipelines: |
include/envoy/server/filter_config.h
Outdated
* @return FilterDependencies specification of dependencies required or | ||
* provided on the decode and encode paths. | ||
*/ | ||
virtual envoy::extensions::filters::common::dependency::v3::FilterDependencies dependencies() { |
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.
With the protos being small I don't think it matters a whole lot, but a unique_ptr might better future proof this in case this changes? I can imagine some filter potentially providing a lot of different dependencies even if none do so today
Signed-off-by: Auni Ahsan <[email protected]>
Signed-off-by: Auni Ahsan <[email protected]>
/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.
This looks good to me, just one nit
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.
Signed-off-by: Auni Ahsan <[email protected]>
Signed-off-by: Auni Ahsan <[email protected]>
Flakes related to #12209 /retest |
Retrying Azure Pipelines: |
/retest |
Retrying Azure Pipelines: |
@snowp /retest seems to be stuck since some of the running tests are still queued, and the failure appears to be a flake. |
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! I restarted CI, let's see how it goes
Commit message:
Additional description: I thought it would be useful to add the interface itself with documentation and get that out of the way, and I noted in the release notes that validation of the dependencies is WIP.
Risk Level: Low.
See design doc attached to #14470 for more details.