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 nil function invocation in client-go/tools/leaderelection #78778
Conversation
Welcome @hbagdi! |
Thanks for your pull request. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA). 📝 Please follow instructions at https://git.k8s.io/community/CLA.md#the-contributor-license-agreement to sign the CLA. It may take a couple minutes for the CLA signature to be fully registered; after that, please reply here with a new comment and we'll verify. Thanks.
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. I understand the commands that are listed here. |
Hi @hbagdi. Thanks for your PR. I'm waiting for a kubernetes member to verify that this patch is reasonable to test. If it is, they should reply with Once the patch is verified, the new status will be reflected by the I understand the commands that are listed here. 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. |
I signed it |
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.
thank you for the PR, i think this make sense, but needs approval by the maintainers.
the 1.15 code freeze will be lifted after 11th of june.
try pinging #sig-api-machinery on slack if needed after that.
/ok-to-test
/priority backlog
staging/src/k8s.io/client-go/tools/leaderelection/leaderelection.go
Outdated
Show resolved
Hide resolved
b1cd519
to
2e2a40c
Compare
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
looks good /assign @mikedanese |
}() | ||
if !le.acquire(ctx) { | ||
return // ctx signalled done | ||
} | ||
ctx, cancel := context.WithCancel(ctx) | ||
defer cancel() | ||
go le.config.Callbacks.OnStartedLeading(ctx) | ||
if le.config.Callbacks.OnStartedLeading != 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.
The other one is fine, but if this is nil, we should probably panic. There's no point to this client if you don't do anything when you get leadership.
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 client could potentially not actively want to be notified of it being a leader and but choose to check the leader status using IsLeader()
function whenever it is actually going to take up any action.
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.
You can do this by providing an empty OnStartedLeading callback. I am hesitant to further facilitate this behavior.
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.
Mike has a good point. That having been said I personally would rather an explicit panic which explained the issue (eg. "Leader elect called without a proper started leading method") than a fatal error about referencing invalid memory.
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.
You can do this by providing an empty OnStartedLeading callback. I am hesitant to further facilitate this behavior.
My take is that zero values in Go shouldn't panic in such a case.
Please let me know the exact change that should be made to move this forward. You guys are more familiar with the API style and end-user expectations here so I'll make a change that works for everyone.
@@ -190,14 +190,18 @@ type LeaderElector struct { | |||
func (le *LeaderElector) Run(ctx context.Context) { | |||
defer func() { | |||
runtime.HandleCrash() | |||
le.config.Callbacks.OnStoppedLeading() |
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.
Sorry I misread this originally. This is intended to crash.
Can you validate that OnStart and OnFinish callbacks are non-nil in NewLeaderElector, else return an error? The interface is designed so that these are explicitly required. If you choose to ignore them (very unadvised), you must do so explicitly. |
2e2a40c
to
906edfd
Compare
@mikedanese updated. Please re-review. |
If user specifies a nil callback, then error out rather than crashing at runtime due to a nil reference.
906edfd
to
9dbbc65
Compare
/lgtm |
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: hbagdi, mikedanese 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 |
How do we fix the failing CI? 🤔 |
/retest |
It should be possible for the user of leaderelection API to not provide
callbacks for stopped and started leading conditions. Currnetly, the
code results in fatal error and exits.
What type of PR is this?
/kind bug
What this PR does / why we need it:
Which issue(s) this PR fixes:
Fixes #
Special notes for your reviewer:
Does this PR introduce a user-facing change?: