-
Notifications
You must be signed in to change notification settings - Fork 38.7k
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 a job quota related deadlock #119776
Fix a job quota related deadlock #119776
Conversation
In case ResourceQuota is used and sets a max # of jobs, a CronJob may get trapped in a deadlock: 1. Job quota for a namespace is reached. 2. CronJob controller can't create a new job, because quota is reached. 3. Cleanup of jobs owned by a cronjob doesn't happen, because a control loop iteration is finished because of an error to create a job. To fix this we stop early quitting from a control loop iteration when cronjob reconciliation failed and always let old jobs to be cleaned up.
Please note that we're already in Test Freeze for the Fast forwards are scheduled to happen every 6 hours, whereas the most recent run was: Sat Aug 5 16:29:46 UTC 2023. |
Welcome @ASverdlov! |
Hi @ASverdlov. 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. |
/ok-to-test code owners should take a look Thanks |
The issue seems to be a valid case. |
LGTM label has been added. Git tree hash: e241d281d3eecc8ba5579be87859f79ead84cd19
|
Changelog suggestion -Fix a cronjob getting stuck when jobs quota is reached
+Fixed an issue where a CronJob could fail to clean up Jobs when the ResourceQuota for Jobs had been reached. |
@@ -435,7 +441,7 @@ func (jm *ControllerV2) syncCronJob( | |||
if !found && !IsJobFinished(j) { | |||
cjCopy, err := jm.cronJobControl.GetCronJob(ctx, cronJob.Namespace, cronJob.Name) | |||
if err != nil { | |||
return nil, nil, updateStatus, err | |||
return cronJob, nil, updateStatus, 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.
Can you add a testcase covering this change 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 changed the code following your suggestion here: #119776 (comment). And we no longer return cronJobCopy
and updateStatus
from jm.syncCronJob()
, but rather accept the pointers to them as parameters, so there is now also no chance to mess them up by chance in this place by returning something different.
/assign |
Now we always call jm.cleanupFinishedJobs() first and then jm.syncCronJob(). We also extract cronJobCopy and updateStatus outside jm.syncCronJob function and pass pointers to them in both jm.syncCronJob and jm.cleanupFinishedJobs to make delayed updates handling more explicit and not dependent on the order in which cleanupFinishedJobs and syncCronJob are invoked.
/retest |
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
/approve
LGTM label has been added. Git tree hash: f41d5421ebacbfdc41c4c502cc017856b8427cdf
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: ASverdlov, soltysh 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 |
@ASverdlov: The following test failed, say
Full PR test history. Your PR dashboard. Please help us cut down on flakes by linking to an open issue when you hit one in your PR. 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. |
/test pull-kubernetes-e2e-kind |
…120321) * Fix a job quota related deadlock In case ResourceQuota is used and sets a max # of jobs, a CronJob may get trapped in a deadlock: 1. Job quota for a namespace is reached. 2. CronJob controller can't create a new job, because quota is reached. 3. Cleanup of jobs owned by a cronjob doesn't happen, because a control loop iteration is finished because of an error to create a job. To fix this we stop early quitting from a control loop iteration when cronjob reconciliation failed and always let old jobs to be cleaned up. * Dont reorder imports * Don't stop requeuing on reconciliation error Previous code only logged the reconciliation error inside jm.sync() and didn't return the reconciliation error to it's invoker processNextWorkItem(). Adding a copy-paste back to avoid this issue. * Remove copy-pasted cleanupFinishedJobs() Now we always call jm.cleanupFinishedJobs() first and then jm.syncCronJob(). We also extract cronJobCopy and updateStatus outside jm.syncCronJob function and pass pointers to them in both jm.syncCronJob and jm.cleanupFinishedJobs to make delayed updates handling more explicit and not dependent on the order in which cleanupFinishedJobs and syncCronJob are invoked. * Return updateStatus bool instead of changing the reference * Explicitly ignore err in tests to fix linter * Fix formatting with update-gofmt.sh
…120320) * Fix a job quota related deadlock In case ResourceQuota is used and sets a max # of jobs, a CronJob may get trapped in a deadlock: 1. Job quota for a namespace is reached. 2. CronJob controller can't create a new job, because quota is reached. 3. Cleanup of jobs owned by a cronjob doesn't happen, because a control loop iteration is finished because of an error to create a job. To fix this we stop early quitting from a control loop iteration when cronjob reconciliation failed and always let old jobs to be cleaned up. * Dont reorder imports * Don't stop requeuing on reconciliation error Previous code only logged the reconciliation error inside jm.sync() and didn't return the reconciliation error to it's invoker processNextWorkItem(). Adding a copy-paste back to avoid this issue. * Remove copy-pasted cleanupFinishedJobs() Now we always call jm.cleanupFinishedJobs() first and then jm.syncCronJob(). We also extract cronJobCopy and updateStatus outside jm.syncCronJob function and pass pointers to them in both jm.syncCronJob and jm.cleanupFinishedJobs to make delayed updates handling more explicit and not dependent on the order in which cleanupFinishedJobs and syncCronJob are invoked. * Return updateStatus bool instead of changing the reference * Explicitly ignore err in tests to fix linter * Fix formatting with update-gofmt.sh
…120319) * Fix a job quota related deadlock In case ResourceQuota is used and sets a max # of jobs, a CronJob may get trapped in a deadlock: 1. Job quota for a namespace is reached. 2. CronJob controller can't create a new job, because quota is reached. 3. Cleanup of jobs owned by a cronjob doesn't happen, because a control loop iteration is finished because of an error to create a job. To fix this we stop early quitting from a control loop iteration when cronjob reconciliation failed and always let old jobs to be cleaned up. * Dont reorder imports * Don't stop requeuing on reconciliation error Previous code only logged the reconciliation error inside jm.sync() and didn't return the reconciliation error to it's invoker processNextWorkItem(). Adding a copy-paste back to avoid this issue. * Remove copy-pasted cleanupFinishedJobs() Now we always call jm.cleanupFinishedJobs() first and then jm.syncCronJob(). We also extract cronJobCopy and updateStatus outside jm.syncCronJob function and pass pointers to them in both jm.syncCronJob and jm.cleanupFinishedJobs to make delayed updates handling more explicit and not dependent on the order in which cleanupFinishedJobs and syncCronJob are invoked. * Return updateStatus bool instead of changing the reference * Explicitly ignore err in tests to fix linter
…120322) * Fix a job quota related deadlock In case ResourceQuota is used and sets a max # of jobs, a CronJob may get trapped in a deadlock: 1. Job quota for a namespace is reached. 2. CronJob controller can't create a new job, because quota is reached. 3. Cleanup of jobs owned by a cronjob doesn't happen, because a control loop iteration is finished because of an error to create a job. To fix this we stop early quitting from a control loop iteration when cronjob reconciliation failed and always let old jobs to be cleaned up. * Dont reorder imports * Don't stop requeuing on reconciliation error Previous code only logged the reconciliation error inside jm.sync() and didn't return the reconciliation error to it's invoker processNextWorkItem(). Adding a copy-paste back to avoid this issue. * Remove copy-pasted cleanupFinishedJobs() Now we always call jm.cleanupFinishedJobs() first and then jm.syncCronJob(). We also extract cronJobCopy and updateStatus outside jm.syncCronJob function and pass pointers to them in both jm.syncCronJob and jm.cleanupFinishedJobs to make delayed updates handling more explicit and not dependent on the order in which cleanupFinishedJobs and syncCronJob are invoked. * Return updateStatus bool instead of changing the reference * Explicitly ignore err in tests to fix linter * Fix formatting with update-gofmt.sh
What type of PR is this?
/kind bug
What this PR does / why we need it:
In case ResourceQuota is used and sets a max # of jobs, a CronJob may get trapped in a deadlock:
To fix this we stop early quitting from a control loop iteration when cronjob reconciliation failed and always let old jobs to be cleaned up.
Which issue(s) this PR fixes:
Fixes #119775
Special notes for your reviewer:
Does this PR introduce a user-facing change?
Additional documentation e.g., KEPs (Kubernetes Enhancement Proposals), usage docs, etc.: