Skip to content

config: scoped rds (2b): support delta APIs in ConfigProvider framework#6781

Merged
htuch merged 12 commits intoenvoyproxy:masterfrom
AndresGuedez:config-provider-delta-api-support
May 9, 2019
Merged

config: scoped rds (2b): support delta APIs in ConfigProvider framework#6781
htuch merged 12 commits intoenvoyproxy:masterfrom
AndresGuedez:config-provider-delta-api-support

Conversation

@AndresGuedez
Copy link
Contributor

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

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>
Signed-off-by: Andres Guedez <aguedez@google.com>
@AndresGuedez
Copy link
Contributor Author

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).

@AndresGuedez
Copy link
Contributor Author

@htuch PTAL

Signed-off-by: Andres Guedez <aguedez@google.com>
@AndresGuedez
Copy link
Contributor Author

/retest

@repokitteh-read-only
Copy link

🤷‍♀️ nothing to rebuild.

🐱

Caused by: a #6781 (comment) was created by @AndresGuedez.

see: more, trace.

Signed-off-by: Andres Guedez <aguedez@google.com>
@htuch htuch requested a review from fredlas May 6, 2019 16:41
@htuch
Copy link
Member

htuch commented May 6, 2019

Would also be good to get @fredlas's eyes on this one as well.

Signed-off-by: Andres Guedez <aguedez@google.com>
Copy link
Member

@htuch htuch left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good modulo comments.
/wait

Copy link
Contributor

@fredlas fredlas left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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");
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ASSERT_FALSE(true) << "some stuff"? Or something like that (I think gtest has some dedicated predicate for this somewhere).

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This virtual function does not return an AssertionResult, so I can't use the gtest ASSERT_*s.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you do ASSERT(false, "some message") then for better readability?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done.

Signed-off-by: Andres Guedez <aguedez@google.com>
htuch
htuch previously approved these changes May 9, 2019
Copy link
Member

@htuch htuch left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@htuch htuch added the waiting label May 9, 2019
Signed-off-by: Andres Guedez <aguedez@google.com>
@AndresGuedez
Copy link
Contributor Author

@fredlas Missed your top level comment earlier:

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.

"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.

Also, in the next sentence, what is the "underlying config proto"? Is that e.g. a ClusterLoadAssignment, RouteConfiguration, etc?

Yes.

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?

It's meant to clarify that the version_ is only set by "dynamic" (i.e., DS API) providers that distribute a version as opposed to "static" providers that are configured via bootstrap.

@fredlas
Copy link
Contributor

fredlas commented May 9, 2019

Thanks!

@htuch htuch merged commit a65e228 into envoyproxy:master May 9, 2019
@AndresGuedez
Copy link
Contributor Author

AndresGuedez commented May 9, 2019

Thanks for the reviews!

mpuncel added a commit to mpuncel/envoy that referenced this pull request May 10, 2019
* 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>
htuch pushed a commit that referenced this pull request May 22, 2019
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>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants