xds: Change how xDS filters are created by introducing Filter.Provider #11883
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
sergiitk
force-pushed
the
xds-filter-provider
branch
2 times, most recently
from
3c0d7e7 to
9b3306d
Compare
sergiitk
force-pushed
the
xds-filter-provider
branch
4 times, most recently
from
dfba410 to
be5f0fa
Compare
sergiitk
changed the title
This is the first step towards supporting filter state retention in Java. The mechanism will be similar to the one described in [A83] (https://github.com/grpc/proposal/blob/master/A83-xds-gcp-authn-filter.md#filter-call-credentials-cache) for C-core, and will serve the same purpose. However, the implementation details are very different due to the different nature of xDS HTTP filter support in C-core and Java. In Java, xDS HTTP filters are backed by classes implementing `io.grpc.xds.Filter`, from here just called "Filters". To support Filter state retention (next PR), Java's xDS implementation must be able to create unique Filter instances per: - Per HCM `envoy.extensions.filters.network.http_connection_manager.v3.HttpConnectionManager` - Per filter name as specified in `envoy.extensions.filters.network.http_connection_manager.v3.HttpFilter.name` This PR **does not** implements Filter state retention, but lays the groundwork for it by changing how filters are registered and instantiated. To achieve this, all existing Filter classes had to be updated to the new instantiation mechanism described below. Prior to these this PR, Filters had no livecycle. FilterRegistry provided singleton instances for a given typeUrl. This PR introduces a new interface `Filter.Provider`, which instantiates Filter classes. All functionality that doesn't need an instance of a Filter is moved to the Filter.Provider. This includes parsing filter config proto into FilterConfig and determining the filter kind (client-side, server-side, or both). This PR is limited to refactoring, and there's no changes to the existing behavior. Note that all Filter Providers still return singleton Filter instances. However, with this PR, it is now possible to create Providers that return a new Filter instance each time `newInstance` is called.
sergiitk
force-pushed
the
xds-filter-provider
branch
from
be5f0fa to
1b72990
Compare
|
Last force-push is a rebase again master and updating commit description. No more force-pushes from this point. |
ejona86
approved these changes
Feb 18, 2025
sergiitk
added a commit
that referenced
this pull request
Mar 6, 2025
This PR adds support filter state retention in Java. The mechanism will be similar to the one described in [A83] (https://github.com/grpc/proposal/blob/master/A83-xds-gcp-authn-filter.md#filter-call-credentials-cache) for C-core, and will serve the same purpose. However, the implementation details are very different due to the different nature of xDS HTTP filter support in C-core and Java. ### Filter instance lifecycle #### xDS gRPC clients New filter instances are created per combination of: 1. `XdsNameResolver` instance, 2. Filter name+typeUrl as configured in HttpConnectionManager (HCM) http_filters. Existing client-side filter instances are shutdown: - A single a filter instance is shutdown when an LDS update contains HCM that is missing filter configuration for name+typeUrl combination of this instance. - All filter instances when watched LDS resource is missing from an LDS update. - All filter instances name resolver shutdown. #### xDS-enabled gRPC servers New filter instances are created per combination of: 1. Server instance, 2. FilterChain name, 3. Filter name+typeUrl as configured in FilterChain's HCM.http_filters Filter instances of Default Filter Chain is tracked separately per: 1. Server instance, 2. Filter name+typeUrl in default_filter_chain's HCM.http_filters. Existing server-side filter instances are shutdown: - A single a filter instance is shutdown when an LDS update contains FilterChain with HCM.http_filters that is missing configuration for filter name+typeUrl. - All filter instances associated with the FilterChain when an LDS update no longer contains FilterChain's name. - All filter instances when watched LDS resource is missing from an LDS update. - All filter instances on server shutdown. ### Related - Part 1: #11883
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This is the first step towards supporting filter state retention in Java. The mechanism will be similar to the one described in A83 for C-core, and will serve the same purpose. However, the implementation details are very different due to the different nature of xDS HTTP filter support in C-core and Java.
In Java, xDS HTTP filters are backed by classes implementing
io.grpc.xds.Filter, from here just called "Filters".To support Filter state retention (next PR), Java's xDS implementation must be able to create unique Filter instances per:
envoy.extensions.filters.network.http_connection_manager.v3.HttpConnectionManagerenvoy.extensions.filters.network.http_connection_manager.v3.HttpFilter.nameThis PR does not implements Filter state retention, but lays the groundwork for it by changing how filters are registered and instantiated. To achieve this, all existing Filter classes had to be updated to the new instantiation mechanism described below.
Prior to these this PR, Filters had no livecycle. FilterRegistry provided singleton instances for a given typeUrl. This PR introduces a new interface
Filter.Provider, which instantiates Filter classes. All functionality that doesn't need an instance of a Filter is moved to the Filter.Provider. This includes parsing filter config proto into FilterConfig and determining the filter kind (client-side, server-side, or both).This PR is limited to refactoring, and there's no changes to the existing behavior. Note that all Filter Providers still return singleton Filter instances. However, with this PR, it is now possible to create Providers that return a new Filter instance each time
newInstanceis called.