-
Notifications
You must be signed in to change notification settings - Fork 40.1k
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
fix goroutine leaks in TestConfigurationChannels #107163
Conversation
@cyclinder: This issue is currently awaiting triage. If a SIG or subproject determines this is a relevant issue, they will accept it by applying the The Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. |
/sig testing |
/test pull-kubernetes-integration |
stopCh = stopChes[0] | ||
} else { | ||
stopCh = wait.NeverStop | ||
} |
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.
Rather than doing this for backwards compatibility, I wonder if it'd be cleaner to add a new method to the type. E.g. ChannelWithContext(ctx context.Context, source string) chan interface{}
.
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.
Actually, this is not in library code (not in staging
) so might just break the signature and update the callers.
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.
hi @ash2k, if we add a new method there, do we need to look at all callers? If so, I would like the PR to add the new method and update TestConfigurationChannels
. Then create a new PR to update all the callers. and decide whether they should call the new method or the old.
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 we don't need yet another method, we can just change this one. The caller should always be responsible for stopping the goroutines they start, so a method without a way to stop them is a bad API. Hence, in my opinion, we should change this one rather just than adding a new one (change bad API to good API).
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 found a lot of code in the kubelet that uses wait.NeverStop, which doesn't seem to care about stopping the goroutine. If we change this method to ChannelWithContext(ctx context.Context, source string) chan interface
, we need to cancel this ctx somewhere uniformly, but I can't find the right place
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.
It's fine, we don't need to fix the world in this PR :)
31d2e39
to
f871c1e
Compare
/cc @dims @dchen1107 |
f871c1e
to
e26370a
Compare
/test pull-kubernetes-unit pull-kubernetes-e2e-kind |
/cc @ash2k |
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
/assign @dims
Signed-off-by: cyclinder <qifeng.guo@daocloud.io>
e26370a
to
928e686
Compare
/test pull-kubernetes-unit |
thanks @cyclinder and @ash2k. the unit test failure seems unrelated, right? /approve |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: ash2k, cyclinder, dims The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
yeah, retest was successful |
/lgtm Thanks! |
Signed-off-by: cyclinder qifeng.guo@daocloud.io
What type of PR is this?
/kind bug
What this PR does / why we need it:
fix goroutine leaks in TestConfigurationChannels.
kubernetes/pkg/util/config/config_test.go
Lines 24 to 34 in ea07644
Which issue(s) this PR fixes:
Fixes #107089
Special notes for your reviewer:
We should consider whether it is appropriate to use wait.NeverStop here:
kubernetes/pkg/util/config/config.go
Line 77 in 13e9745
Does this PR introduce a user-facing change?
Additional documentation e.g., KEPs (Kubernetes Enhancement Proposals), usage docs, etc.: