-
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
config: distinct resource/transport API versions. #9526
Conversation
This PR extends envoyproxy#9468 to support a distinct notion of transport and resource API version. The intuition here is that the opaque resources (and their type URLs) can be delivered via either v2 or v3 xDS, and the DiscoveryRequest etc. messages have their own versioning. Currently, the v2 and v3 transport protocols are indistinguishable modulo service endpoint. As v3 evolves, e.g. with envoyproxy#9301, differences will be introduced. At this point it will be necessary to have enhanced support in the gRPC mux and HTTP subscription modules to handle the protocol differences. This is technically a breaking v2 API change, but since the field it breaks was only added today, I think it's safe to assume it is not in use yet. Risk level: Low Testing: Integration tests added to validate service endpoint and type URL selection based on transport/resource version. Signed-off-by: Harvey Tuch <htuch@google.com>
@Shikugawa @lizan the |
Signed-off-by: Harvey Tuch <htuch@google.com>
Signed-off-by: Harvey Tuch <htuch@google.com>
Signed-off-by: Harvey Tuch <htuch@google.com>
Signed-off-by: Harvey Tuch <htuch@google.com>
Signed-off-by: Harvey Tuch <htuch@google.com>
Signed-off-by: Harvey Tuch <htuch@google.com>
Signed-off-by: Harvey Tuch <htuch@google.com>
Signed-off-by: Harvey Tuch <htuch@google.com>
Signed-off-by: Harvey Tuch <htuch@google.com>
@lizan @Shikugawa @mattklein123 this now has tests added for functional coverage and is ready for review. |
@htuch Great thanks for this work. This is very helpful functionality for my planning implementation for API fallback. I will add some comment. |
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.
At a high level this looks fine to me with one API question.
Signed-off-by: Harvey Tuch <htuch@google.com>
Signed-off-by: Harvey Tuch <htuch@google.com>
Previously, type_to_endpoint.cc had a lot of hardcoding, which doesn't scale well with multiple API versions. See envoyproxy#9526 for an example of the issues encountered. This patch switches to using explicit resource type annotations on service descriptors, which is great for documentation (previously this was sometimes given in comments, sometimes not), and allows for a reflection driven reverse map from resource type URL to endpoints to be built at runtime. Risk level: Low Testing: New unit tests for type_to_endpoint.cc and golden protoxform tests for the new annotations. Fixes envoyproxy#9454. Signed-off-by: Harvey Tuch <htuch@google.com>
#9566) Previously, type_to_endpoint.cc had a lot of hardcoding, which doesn't scale well with multiple API versions. See #9526 for an example of the issues encountered. This patch switches to using explicit resource type annotations on service descriptors, which is great for documentation (previously this was sometimes given in comments, sometimes not), and allows for a reflection driven reverse map from resource type URL to endpoints to be built at runtime. Risk level: Low Testing: New unit tests for type_to_endpoint.cc and golden protoxform tests for the new annotations. Fixes #9454. Signed-off-by: Harvey Tuch <htuch@google.com>
…. (#9566) Previously, type_to_endpoint.cc had a lot of hardcoding, which doesn't scale well with multiple API versions. See envoyproxy/envoy#9526 for an example of the issues encountered. This patch switches to using explicit resource type annotations on service descriptors, which is great for documentation (previously this was sometimes given in comments, sometimes not), and allows for a reflection driven reverse map from resource type URL to endpoints to be built at runtime. Risk level: Low Testing: New unit tests for type_to_endpoint.cc and golden protoxform tests for the new annotations. Fixes #9454. Signed-off-by: Harvey Tuch <htuch@google.com> Mirrored from https://github.com/envoyproxy/envoy @ cceab393664429a3063d787cf28cade3c8ab01c7
Signed-off-by: Harvey Tuch <htuch@google.com>
@mattklein123 @lizan ready for another pass, 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.
LGTM at a high level. Will defer to @lizan and @Shikugawa for in-depth review.
Signed-off-by: Harvey Tuch <htuch@google.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.
LGTM, one nit
#9526 force linked most method descriptors. However, HDS was missing. This PR force links HDS v2. Risk Level: low Testing: compiled with Envoy Mobile's iOS dist target which, as discussed here, requires the hack currently in place. Signed-off-by: Jose Nino <jnino@lyft.com>
This is only refactoring. Aggregated xDS type urls. In previous implementation, loadTypeUrl is scattered on all of xDS subscription classes. That is poor outlook so refactored all of them. Risk Level: Low Testing: None Relates to issues 9468 #9526 Signed-off-by: shikugawa <rei@tetrate.io>
This PR extends #9468 to support a distinct notion of transport and
resource API version. The intuition here is that the opaque resources
(and their type URLs) can be delivered via either v2 or v3 xDS, and the
DiscoveryRequest etc. messages have their own versioning.
Currently, the v2 and v3 transport protocols are indistinguishable
modulo service endpoint. As v3 evolves, e.g. with #9301, differences
will be introduced. At this point it will be necessary to have enhanced
support in the gRPC mux and HTTP subscription modules to handle the
protocol differences.
This is technically a breaking v2 API change, but since the field it
breaks was only added today, I think it's safe to assume it is not in
use yet.
Some other misc. changes that were needed:
DiscoveryRequest
.Risk level: Medium (introduction of type URL in REST
DiscoveryRequest
s is a wire addition.Testing: Integration tests added to validate service endpoint and type
URL selection based on transport/resource version.
Signed-off-by: Harvey Tuch htuch@google.com