-
Notifications
You must be signed in to change notification settings - Fork 4.5k
xds/xdsclient: create LRSClient at time of initialisation #8483
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
base: master
Are you sure you want to change the base?
Conversation
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## master #8483 +/- ##
==========================================
- Coverage 82.47% 82.46% -0.02%
==========================================
Files 413 413
Lines 40513 40537 +24
==========================================
+ Hits 33415 33429 +14
- Misses 5743 5748 +5
- Partials 1355 1360 +5
🚀 New features to boost your workflow:
|
for i := 0; i < numGoroutines; i++ { | ||
go func() { | ||
store, cancelStore := client.ReportLoad(serverConfig) | ||
if store != nil { |
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.
Why do we need this check? Why is the store
nil?
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 can return nil in case of error, but in that case the cancelStore function will be a no-op function , so we can skip this check.
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.
Do we expect an error to be returned in the test? If not, we should error log it to fail the test. My concern is that the current check may hide failures.
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.
Right! Got your point. It will return nil in case that the XDSClient does not have lrsclient field set. So I think it makes sense to log an error if it is not set , because we want to set it unconditionally at time of creation. Does that sound good?
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 had a look at the code again and I feel that we should get rid of the nil
check entirely. We set the field at object creation time, so it should be impossible for it to be nil
.
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.
Got it! Done.
for i := 0; i < numGoroutines; i++ { | ||
go func() { | ||
store, cancelStore := client.ReportLoad(serverConfig) | ||
if store != nil { |
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 had a look at the code again and I feel that we should get rid of the nil
check entirely. We set the field at object creation time, so it should be impossible for it to be nil
.
TransportBuilder: gConfig.TransportBuilder, | ||
}) | ||
if err != nil { | ||
return nil, 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.
Now that we have moved it out of report load, we might have think a bit more here. Should error in lrs client creation be fatal? because not everyone is going to use internal xdsclient for load reporting.
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.
In my opinion, we should keep the same behaviour as before the xDS client migration changes. If there are certain users who need to ignore LRS client creation failures, we can create a new issue to discuss if the bahviour changes makes sense.
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 it makes sense to retain the behavior of making LRS client creation failures be fatal. But we might want to change one minor thing in lrsclient.New
. Currently it fails if node ID is empty in the configuration. We recently removed that check for the xDS client creation. I'm guessing other languages might not treat this as fatal for LRS creation.
@eshitachandwani : Could you please check what the other languages do and if required remove the check for empty node ID in lrsclient.New
. 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.
If I understand correctly , Java is checking for not null here
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.
That check is for the whole node
proto or struct. Not just the node ID field.
TransportBuilder: gConfig.TransportBuilder, | ||
}) | ||
if err != nil { | ||
return nil, 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.
I think it makes sense to retain the behavior of making LRS client creation failures be fatal. But we might want to change one minor thing in lrsclient.New
. Currently it fails if node ID is empty in the configuration. We recently removed that check for the xDS client creation. I'm guessing other languages might not treat this as fatal for LRS creation.
@eshitachandwani : Could you please check what the other languages do and if required remove the check for empty node ID in lrsclient.New
. Thanks.
for i := 0; i < numGoroutines; i++ { | ||
go func() { | ||
defer wg.Done() | ||
_, cancelStore := client.ReportLoad(serverConfig) |
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.
Would it make sense to have a loop here 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.
I am not sure if I understand, loop for what?
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.
A loop inside the goroutine to start reporting load and subsequently canceling it. What I'm asking for is:
for i := 0; i < numGoroutines; i++ {
go func() {
defer wg.Done()
for j := 0; j < 100; j++ {
_, cancelStore := client.ReportLoad(serverConfig)
cancelStore(ctx)
}
}()
}
Fixes: #8474
The race is in ReportLoad function of clientImpl. The implementation was recently changed as the part of xds client migration.
The comment says that
lrsclient.LRSClient
should be initialized only at creation time but that was not the case. It was being initialized at the time of callingReportLoad
function.RELEASE NOTES: N/A