config: scoped rds (2b): support delta APIs in ConfigProvider framework#6781
Conversation
An xDS delta API receives a subset of the config set as part of each resource contained in a DiscoveryResponse. An example of this type of API is CDS. Signed-off-by: Andres Guedez <aguedez@google.com>
…elta-api-support Signed-off-by: Andres Guedez <aguedez@google.com>
Signed-off-by: Andres Guedez <aguedez@google.com>
|
For context, refer to PR #5839 which includes the full set of changes which will be introduced by this PR chain (note that there are a few minor differences with this PR as a result of further testing and cleanup). |
|
@htuch PTAL |
|
/retest |
|
🤷♀️ nothing to rebuild. |
|
Would also be good to get @fredlas's eyes on this one as well. |
htuch
left a comment
There was a problem hiding this comment.
Looks good modulo comments.
/wait
There was a problem hiding this comment.
In the class level comment for ConfigProvider,
Use config() to obtain a shared_ptr to the implementation of the config
I don't understand what "implementation of the config" means. Also, in the next sentence, what is the "underlying config proto"? Is that e.g. a ClusterLoadAssignment, RouteConfiguration, etc? And, is the parenthetical at the end saying configProtoInfo() is only applicable to dynamic config, or that just the part of it providing version is only applicable to dynamic config?
Signed-off-by: Andres Guedez <aguedez@google.com>
Signed-off-by: Andres Guedez <aguedez@google.com>
Signed-off-by: Andres Guedez <aguedez@google.com>
| ConfigProviderPtr | ||
| createStaticConfigProvider(std::vector<std::unique_ptr<const Protobuf::Message>>&&, | ||
| Server::Configuration::FactoryContext&, const OptionalArg&) override { | ||
| ASSERT(false || "this provider does not expect multiple config protos"); |
There was a problem hiding this comment.
ASSERT_FALSE(true) << "some stuff"? Or something like that (I think gtest has some dedicated predicate for this somewhere).
There was a problem hiding this comment.
This virtual function does not return an AssertionResult, so I can't use the gtest ASSERT_*s.
There was a problem hiding this comment.
Can you do ASSERT(false, "some message") then for better readability?
Signed-off-by: Andres Guedez <aguedez@google.com>
htuch
left a comment
There was a problem hiding this comment.
Thanks, LGTM, I grok the subtractive updates at https://github.com/envoyproxy/envoy/pull/5839/files#diff-1578b366b91c6312bf7d120645d32b22R160.
Signed-off-by: Andres Guedez <aguedez@google.com>
|
@fredlas Missed your top level comment earlier:
"Implementation of the config" means the Envoy logic that actually translates the config intent into Envoy actions. For example, RDS' config implementation is found at Envoy::Router::ConfigImpl, and CDS's logic is found in cluster_manager_impl.cc.
Yes.
It's meant to clarify that the |
|
Thanks! |
|
Thanks for the reviews! |
* master: (88 commits) upstream: Null-deref on TCP health checker if setsockopt fails (envoyproxy#6793) ci: switch macOS CI to azure pipelines (envoyproxy#6889) os syscalls lib: break apart syscalls used for hot restart (envoyproxy#6880) Kafka codec: precompute request size before serialization, so we do n… (envoyproxy#6862) upstream: move static and strict_dns clusters to dedicated files (envoyproxy#6886) Rollforward of api: Add total_issued_requests to Upstream Locality and Endpoint Stats. (envoyproxy#6692) (envoyproxy#6784) fix explicit constructor in copy-initialization (envoyproxy#6884) stats: use tag iterator rather than constructing the tag-array and searching that. (envoyproxy#6853) common: use unscoped build target in generate_version_linkstamp (envoyproxy#6877) Addendum to envoyproxy#6778 (envoyproxy#6882) ci: add minimum Linux build for Azure Pipelines (envoyproxy#6881) grpc: utilities for inter-converting grpc::ByteBuffer and Buffer::Instance. (envoyproxy#6732) upstream: allow excluding hosts from lb calculations until initial health check (envoyproxy#6794) stats: prevent unused counters from leaking across hot restart (envoyproxy#6850) network filters: add `injectDataToFilterChain(data, end_stream)` method to network filter callbacks (envoyproxy#6750) delete things that snuck back in (envoyproxy#6873) config: scoped rds (2b): support delta APIs in ConfigProvider framework (envoyproxy#6781) string == string! (envoyproxy#6868) config: add mssing imports to delta_subscription_state (envoyproxy#6869) protobuf: add missing default case to enum (envoyproxy#6870) ... Signed-off-by: Michael Puncel <mpuncel@squareup.com>
Implement the scoped RDS (SRDS) API config subscription and provider based on the config protos introduced in #6675 and the ConfigProvider framework introduced in #5243 and #6781. NOTES: See parent PR #5839 for full context into these changes. PRs 2a (#6675) and 2b (#6781) have already been merged. The API is not yet fully implemented. This PR introduces static and dynamic (xDS config subscription) handling of scoped routing configuration, but the new L7 multi tenant routing logic (see #4704) has not yet been introduced. The API is not yet plumbed into the HttpConnectionManager, that will be done in the next PR. This PR includes unit tests only; integration tests will follow in the next PR. Risk Level: Low (this DS API is not yet integrated into the HCM and can not be enabled via config). Testing: Unit tests added. Docs Changes: N/A. Signed-off-by: Andres Guedez <aguedez@google.com>
Add support for "delta" APIs to the ConfigProvider framework in preparation for scoped RDS (see #4704).
A delta API receives a subset of the configuration set through each resource distributed via the *DiscoveryResponse messages.
While this PR is not directly related to the ongoing incremental xDS effort, it creates the foundation in the ConfigProvider framework to support Delta xDS updates for APIs implemented on top of the framework.
Risk Level: Low (there is no DS API yet using this framework)
Testing: Unit tests added, all existing tests passing.
Docs Changes: N/A
Release Notes: N/A