-
Notifications
You must be signed in to change notification settings - Fork 4.9k
fcds: add unimplemented api #39154
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
fcds: add unimplemented api #39154
Conversation
Signed-off-by: Ohad Vano <ohadvano@gmail.com>
CC @envoyproxy/api-shepherds: Your approval is needed for changes made to |
Signed-off-by: Ohad Vano <ohadvano@gmail.com>
Signed-off-by: ohadvano <49730675+ohadvano@users.noreply.github.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!
cc @markdroth
Signed-off-by: Ohad Vano <ohadvano@gmail.com>
Signed-off-by: Ohad Vano <ohadvano@gmail.com>
@markdroth, @adisuissa please review latest iteration |
This looks good to me! I'll defer to @wbpcode as the designated API reviewer. |
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. Thanks.
Additional Description: Adding unimplemented FCDS API as a first step in roadmap to support this feature. See envoyproxy#39141 for feature description. Most of the specifications are described inline with the API changes but for extra clarity I will describe them here: - Current FCDS implementation is intended to discover a filter chain object (including its name) - It's meant to support both delta and SoTW APIs - A discovery request should include the containing context name. The containing context can either be customized per discovery in the config or derived by the listener's name. - A listener may contain both statically configured filter chains as well as runtime discovered filter chains. However, if a discovered filter chain matches any of another existing filter chain, its configuration is discarded (this will be later indicated by metrics and/or logs). - The model here is very similar to how EDS works. A cluster owns an EDS subscription. It uses a custom service name or the cluster name in the discovery request and the server responds with a list of endpoints. In this discovery service, the listener owns the FCDS subscription, mentioned by the listener name or custom configured name, and the server responds with list of filter chains. Example usage: ``` static_resources: listeners: - name: tcp_listener_1 stat_prefix: tcp_listener address: socket_address: protocol: TCP address: 0.0.0.0 port_value: 1111 filter_chains: - name: some_static_filter_chain filters: - filter_1 - filter_2 fcds_config: name: tcp_listener_1_dynamic_filter_chains config_source: api_config_source: api_type: GRPC transport_api_version: V3 grpc_services: - envoy_grpc: cluster_name: xds_cluster ``` Risk Level: low Testing: none Docs Changes: API Release Notes: none Platform Specific Features: none --------- Signed-off-by: Ohad Vano <ohadvano@gmail.com> Signed-off-by: ohadvano <49730675+ohadvano@users.noreply.github.com> Signed-off-by: Jacob Lisi <jtlisi@google.com>
Additional Description: Adding unimplemented FCDS API as a first step in roadmap to support this feature. See #39141 for feature description. Most of the specifications are described inline with the API changes but for extra clarity I will describe them here:
Example usage:
Risk Level: low
Testing: none
Docs Changes: API
Release Notes: none
Platform Specific Features: none