Skip to content
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

Merged
merged 1 commit into from
Aug 4, 2023

Conversation

dfawley
Copy link
Member

@dfawley dfawley commented Aug 3, 2023

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

Copy link
Contributor

@zasweq zasweq left a 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)
Copy link
Contributor

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?

Copy link
Contributor

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?

Copy link
Contributor

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.

Copy link
Member Author

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.

@zasweq zasweq assigned dfawley and unassigned zasweq Aug 3, 2023
@dfawley dfawley merged commit 8ebe462 into grpc:master Aug 4, 2023
11 checks passed
@dfawley dfawley deleted the odSCL branch August 10, 2023 22:14
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Feb 7, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants