-
Notifications
You must be signed in to change notification settings - Fork 4.5k
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
xds: introduce generic xds clients xDS and LRS Client API signatures #8042
xds: introduce generic xds clients xDS and LRS Client API signatures #8042
Conversation
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## master #8042 +/- ##
==========================================
+ Coverage 82.32% 82.36% +0.03%
==========================================
Files 388 392 +4
Lines 39016 39132 +116
==========================================
+ Hits 32121 32232 +111
- Misses 5574 5585 +11
+ Partials 1321 1315 -6
🚀 New features to boost your workflow:
|
042b236
to
f8f7af5
Compare
f8f7af5
to
415b2ca
Compare
@dfawley i did the godoc review and made following changes (see the last commit)
|
// Servers specifies a list of xDS servers to connect to. This field should | ||
// be used only for old-style names without an authority. |
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.
Let's leave "old" and "style" out of the docstrings and describe what it is or what it is used for in specific terms instead.
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 have modified the documentation. One more thing i have added in both Authority and here about order of servers in the list for precedence. Let me know if thats okay. I remember there was a question recently about how the fallback servers are chosen. Should we mention the gRFC as well?
20e26f8
to
c3e96f7
Compare
ff89334
to
9b003bc
Compare
9b003bc
to
0d234e0
Compare
@dfawley I have moved the config helpers and test to internal package because 1) we don't want to expose them 2) we don't want user to have proto dependencies. |
a25d436
to
7cbeb43
Compare
7cbeb43
to
833a19b
Compare
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.
This seems basically done, just some very minor things left.
|
||
// IsServerIdentifierEqual returns true if clients.ServerIdentifier si1 and si2 | ||
// are considered equal. | ||
func IsServerIdentifierEqual(si1, si2 *clients.ServerIdentifier) bool { |
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.
Is xdsclient using this? If so, how? I was thinking it would just be the transport implementation that needs something like it?
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.
So, it will be used to de-duplicate the transport channel. Yes, the transport will need it. Also, when de-duplicating xDS channel the xDS ServerConfig equality check will call it as well.
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.
So then only our transport implementation can use it if it's in internal
. Maybe let's delete for now and add when needed and we can talk about how it should work and where it should go.
Because what we really need is ServerIdentifiers
as map keys. But that's not directly possible, unless the any
is compatible, perhaps?
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.
Think its the same discussion #8042 (comment). Basically, it will be needed in xDS client implementation as well for server config because ServerIdentifier is embedded in that.
// such as an xDS management or an LRS server. | ||
type ServerConfigExtension struct { | ||
type ServerIdentifierExtension struct { |
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.
We don't have an Equal
method, but our own docs recommend one? Are we sure we actually need one? If only the transport would need it, then I don't think we 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.
We will need it when de-duplicating the transport channel. That will come in final xDS client implementation PR. I was thinking of adding it at that time. Why do you think we won't need one?
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.
Deduplicating will require it to be a map key, not to have an Equal
method.
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 don't think we can hash the complex fields like extensions right? So, we need a equal method to get the right key for the map and then lookup that key. Something like done here for xDS Server Config
grpc-go/xds/internal/xdsclient/authority.go
Line 531 in bffa4be
if a.activeXDSChannel != nil && a.activeXDSChannel.serverConfig.Equal(serverConfig) { |
So, ServerConfig needs equal method and in turn we need to check equality for embedded ServerIdentifier. I don't think we can get away without equality unless every field has a String() method.
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.
@easwars 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.
Discussed internally with @dfawley. For now, we can remove and see if we can find other ways to tackle comparing channels.
1f74716
to
60166b7
Compare
4f55bfc
to
b6ac539
Compare
This is the next part of generic xds clients to be usable outside of grpc which builds on top of #8024. This change is adding the user API signatures for xDS and LRS client (without implementation) to communicate with xDS management server.
POC
Internal Design
RELEASE NOTES: None