-
Notifications
You must be signed in to change notification settings - Fork 1.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
fix(pkg/repository/maintenance): handle when there's no container status #8271
base: main
Are you sure you want to change the base?
Conversation
Hi @mateusoliveira43 , sure, I've updated the comments and the error |
if you're like me, you'd notice rust would have made the problem much more obvious in the first place 😅 |
@mcluseau yeah, Go errors are almost unreadable, thanks for taking time to fix this! |
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #8271 +/- ##
==========================================
- Coverage 59.21% 59.21% -0.01%
==========================================
Files 367 367
Lines 30841 30849 +8
==========================================
+ Hits 18262 18266 +4
- Misses 11119 11121 +2
- Partials 1460 1462 +2 ☔ View full report in Codecov by Sentry. |
@mcluseau please add changelog |
Add changelog here |
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.
IMO. but not blocked on it.
|
||
statuses := pod.Status.ContainerStatuses | ||
if len(statuses) == 0 { | ||
return "", fmt.Errorf("no container statuses found for job %s", job.Name) |
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 termination-log is not always written, it is only written when maintenance fails.
So I suspect it is a non-error case when len(statuses) == 0
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.
to me, "no statuses" is not the expected state even if the container terminated successfully:
https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle/#container-state-terminated
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 may have pointed the comment to wrong code. The most suspecting line is below:
terminated := statuses[0].State.Terminated
if terminated == nil {
return "", fmt.Errorf("container for job %s is not terminated", job.Name)
As you can see from the maintenance code, if the maintenance succeeds, no termination message is written, so statuses[0].State.Terminated
may indeed be nil. But this is a normal case.
Furthermore, when nothing is set to pod.Status.ContainerStatuses
, will it be nil? If so, it is still a normal case.
Please double confirm 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.
I answered to the State.Terminated
case too :) there's not just the termination log, there's also the exit code, time, etc.
About container statuses, they are expected to be filled (from waiting to running to terminated) but they may not be present when the pod was just created (I guess a kind of race condition leads the initial but mentioned here). So, my interpretation is that when it's empty, it's not a normal state and can't be after the container's termination: ie, the caller made the call too soon for some reason, very in line with semantics of asking before the pod was created by the job, which is a case that returns an error.
…r statuses Signed-off-by: Mikaël Cluseau <[email protected]>
Fixes a crash in this case.