-
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
outlierdetection: fix unconditional calls of child UpdateSubConnState #6500
Conversation
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.
Oh I see, so your old pr persisted the listener callback only in the update from parent flow. This persists it in the scw to forward it down and branch on both update types.
}) | ||
} | ||
|
||
func (b *outlierDetectionBalancer) UpdateSubConnState(sc balancer.SubConn, state balancer.SubConnState) { | ||
b.updateSubConnState(sc, state, nil) | ||
b.logger.Errorf("UpdateSubConnState(%v, %+v) called unexpectedly", sc, state) |
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 get how if this logs an error and doesn't do anything do we keep it backward compatible?
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 not just keep the old flow the same (UpdateSubConnState works normally), until we delete? What's the advantage of this?
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.
Oh, I guess this won't ever get called since the Channel now calls the listener callback.
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 not just keep the old flow the same (UpdateSubConnState works normally), until we delete? What's the advantage of this?
The goal is to catch all the places where we use the old API and update them to the new one so the old one can be deleted. If we keep the old API code working then we might miss a place where we needed to convert it when we go to delete the API itself.
If a child policy had a state listener for SubConn updates, we should invoke it directly instead of calling UpdateSubConnState. Change #6481 properly forwarded updates from the parent, but missed the synthesized calls into the child to eject/uneject that originated from the outlierdetection policy itself.
RELEASE NOTES: none