-
Notifications
You must be signed in to change notification settings - Fork 4.4k
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: add xDS transport custom dial options support #7997
Conversation
@yousukseung we are not updating transport to use this instead yet? |
I removed I don't see any change needed in transport though. All changes I'm making is internal to |
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## master #7997 +/- ##
==========================================
+ Coverage 82.04% 82.19% +0.14%
==========================================
Files 384 384
Lines 38750 38929 +179
==========================================
+ Hits 31792 31996 +204
+ Misses 5632 5595 -37
- Partials 1326 1338 +12
|
I haven't completed the review but adding @easwars as well to review in parallel |
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.
Tested end-to-end in prod, the current commit work as expected.
// testCredsBuilder implements the `Credentials` interface defined in | ||
// package `xds/bootstrap` and encapsulates an insecure credential with a | ||
// custom Dialer that specifies how to dial the xDS server. | ||
type testCredsBuilder struct { | ||
dialerCalled atomic.Bool | ||
tagRPCCalled atomic.Bool | ||
handleRPCCalled atomic.Bool | ||
tagConnCalled atomic.Bool | ||
handleConnCalled atomic.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.
I think the doc string does not align with what the struct actually is? This both a custom Dialer and stats Handler.
I presume this xds_client_custom_dialopts_test.go
file was originally copied from test/xds/xds_client_custom_dialer_test.go
in #7586 but some changes were not updated?
Would the plan in the next PR, once internal/prod changes were made, to delete xds_client_custom_dialer_test.go
?
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.
Yes lazy copy & paste. I removed the description, I think all we need is to tell what it extends, the rest seems obvious from reading.
|
||
// noopStatsHandler implements `stats.Handler`. It's a no-op mock handler. | ||
type noopStatsHandler struct { | ||
tagRPCCalled *atomic.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.
What would be the reason for using *atomic.Bool
instead of just atomic.Bool
?
Also see below comment regarding using sync/atomic
package vs channel
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 believe the way things are setup instantiates atomics in testCredsBuilder
, then I saw no reason to copy. Or anything I missed?
// stats handler. | ||
type testCredsBundle struct { | ||
credentials.Bundle | ||
dialerCalled *atomic.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.
We switched from using chan struct{}
(in xds_client_custom_dialer_test.go
) to the atomic package.
Channel are used for communication between goroutines (but it can also be used as mutex/atomic synchronization). In this case, I think we should be OK as we are using it for "one-time" signaling / synchronization between goroutines. Looking at https://go.dev/ref/mem, I don't see any issues.
@easwars what would be the preferred approach here? Would there be any issues switching from channel to atomic? From Go tips/best practices, it is recommended to use channel for one-time signaling.
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.
AFAICT channel seems to be the obvious choice if you need to block on the event you expect. But here we can ensure expected events (both the dialer and stats handler) should have happened before we validate as we call cc.Close()
first (commented). Plus for stats handler atomic simply works better as we expect multiple events but all we want to check is the presence of any.
@purnesh42H @easwars kindly ping to unblock prod monitoring visibility. |
Overall it looks good to me. Few comments regarding removing some extra stuff that we have right now. |
// data plane communication with the test backend. | ||
cc, err := grpc.NewClient(fmt.Sprintf("xds:///%s", serviceName), grpc.WithTransportCredentials(insecure.NewCredentials()), grpc.WithResolvers(resolverBuilder)) | ||
if err != nil { | ||
t.Fatalf("failed to dial local test server: %v", err) |
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.
Nit: s/failed/Failed
The non-capitalization of error strings don't apply to test error messages.
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.
Done.
@purnesh42H : Do you want to take another look? |
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
This PR extends #7586 to support multiple custom dial options.
The custom dialer option added in PR#7586 is now deprecated but not removed yet. This will be removed in a future PR after dependencies are moved to the new option.
RELEASE NOTES: N/A