-
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
router: scoped rds (2a): scoped routing configuration protos #6675
router: scoped rds (2a): scoped routing configuration protos #6675
Conversation
Protos to statically and dynamically (via the Scoped Route Discovery Service) configure scoped routing logic in Envoy. 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. |
@htuch PTAL |
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.
Great, these are awesome proto comments. I would encourage anyone in the Envoy community who cares about the design-level aspect of multi-tenancy to give this a read, it is a significant part of the story (@envoyproxy/maintainers).
LGTM modulo a few comments.
/wait
api/envoy/config/filter/network/http_connection_manager/v2/http_connection_manager.proto
Outdated
Show resolved
Hide resolved
api/envoy/config/filter/network/http_connection_manager/v2/http_connection_manager.proto
Show resolved
Hide resolved
api/envoy/config/filter/network/http_connection_manager/v2/http_connection_manager.proto
Show resolved
Hide resolved
Signed-off-by: Andres Guedez <aguedez@google.com>
@lizan @mattklein123 @snowp would one of you like to volunteer as a non-Googler reviewers of this API? I'm pretty happy with the current state modulo unresolved comments. |
Yes I would like to review this, but it will take a few days. Sorry for the delay. |
/retest |
🔨 rebuilding |
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 this generally looks great. A few comments that I think can help around readability. This is a great feature and I want to make sure people can read the docs and understand it.
/wait
// | ||
// [#comment:next free field: 4] | ||
// [#proto-status: experimental] | ||
message ScopedRouteConfiguration { |
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 wonder whether this message should be in the same file as the related HCM protos? Is there any compelling reason to split them like this? It seems like they are very closely related? Don't have a strong opinion on this but putting all of the required definitions together in an srds.proto
might make this complicated feature easier to grok? WDYT?
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.
My intent is to maintain consistency by having the xDS API "top-level" proto specification under api/envoy/api/v2
.
I found it more readable to have the ScopedRoutes
proto defined in the http_connection_manager.proto
along its consumer rather than pairing it with the ScopedRouteConfiguration
proto here. However, this may just be my bias being the implementor so I can certainly consolidate the protos into srds.proto if that is more approachable for those with less context.
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.
@htuch thoughts here? My preference is to keep them together for readability, but I don't feel strongly about it if others do.
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 the split is reasonable to me, given how the service and the builder are used. I think it might even warrant moving to a separate peer proto alongside HCM config (but same package namespace) as it's self-contained, but we can do that optionally in a followup.
api/envoy/config/filter/network/http_connection_manager/v2/http_connection_manager.proto
Show resolved
Hide resolved
api/envoy/config/filter/network/http_connection_manager/v2/http_connection_manager.proto
Outdated
Show resolved
Hide resolved
Signed-off-by: Andres Guedez <aguedez@google.com>
Thanks, LGTM modulo the question of whether to merge the protos or not. Will let @htuch weigh in on that. /wait-any |
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.
Great, thanks!
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.
Very nice.
* master: (35 commits) Revert "api: Add total_issued_requests to Upstream Locality and Endpoint Stats. (envoyproxy#6692)" (envoyproxy#6761) Add test for the SocketOptionFactory::buildLiteralOptions() method. (envoyproxy#6724) Add test of parsing weighted_cluster route configuration to improve test coverage. (envoyproxy#6711) test: reducing H2 test permutations, increasing coverage time (envoyproxy#6753) Support gRPC-JSON translate without the google.api.http option. (envoyproxy#6731) quiche: implement QuicEpollClock (envoyproxy#6745) http: rc details for main Envoy workflow (envoyproxy#6560) quiche: implement QuicSystemEventLoopImpl (envoyproxy#6723) http: tracking 100s from upstream in stats (envoyproxy#6746) coverage: run without deprecated option (envoyproxy#6752) quiche: Implement spdy_test_helpers_impl. (envoyproxy#6741) [test] convert listener test stubs to v2 API (envoyproxy#6735) api: Add total_issued_requests to Upstream Locality and Endpoint Stats. (envoyproxy#6692) quiche: Implement http2_reconstruct_object_impl.h. (envoyproxy#6717) build: patch protobuf for UBSAN issue. (envoyproxy#6721) router: scoped rds (2a): scoped routing configuration protos (envoyproxy#6675) tap: use move semantics for submitTrace (envoyproxy#6709) quiche: add epoll_server for testing (envoyproxy#6650) Increase timeout of the coverage test run to 3000 seconds as it is now bumping in the current 2000s limit causing coverage run to abort sometimes. (envoyproxy#6722) quiche: Update tarball to commit 43a1c0f10f2855c3cd142f500e8d19ac6d6f5a8c (envoyproxy#6718) ... Signed-off-by: Michael Puncel <mpuncel@squareup.com>
…oxy#6675) Protos to statically and dynamically (via the Scoped Route Discovery Service) configure scoped routing logic in Envoy. Signed-off-by: Andres Guedez <aguedez@google.com> Signed-off-by: Jeff Piazza <jeffpiazza@google.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>
This PR introduces the configuration protos required for scoped routing support (#4704).
This is the second chain of PRs for SRDS support. This chain will be split up into multiple PRs in the following cadence:
Risk Level: Low (the protos are not yet referenced by any code)
Testing: None (will be introduced in the next PR)