-
Notifications
You must be signed in to change notification settings - Fork 40
Notebooks 2.0 // Controller // Extract All Container Statuses to State #212
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
Comments
/assign @harshad16 |
@ederign: GitHub didn't allow me to assign the following users: harshad16. Note that only kubeflow members with read permissions, repo collaborators and people who have commented on this issue/PR can be assigned. Additionally, issues/PRs can only have 10 assignees at the same time. In response to this:
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. |
As discussed at the community meeting, I would like to pick this ticket to work on it. |
I just wanted to highlight that we made a small change to the Workspace state generation in #240. The change now extracts Pod events when we cant figure out why a Pod is not running, but its not going to fix the issue listed above, so we still need to handle extracting container status info about non- |
As raised by @harshad16 in #210, there is an issue with the
generateWorkspaceState()
method in the Workspace controller.The issue is that we only look at the
main
container's status when checking for issues likeImagePullBackOff
, but there could be multiplecontainer
orinitContainers
with issues preventing the Pod from becoming ready.We need to update the following code so that it looks at all the container statuses in the Pod's
status.containerStatuses
andstatus.initContainerStatuses
and looks for any which are in a "waiting" state withCrashLoopBackOff
orImagePullBackOff
reasons, and then aggregate the errors into the stateMessage.notebooks/workspaces/controller/internal/controller/workspace_controller.go
Lines 1051 to 1076 in 6f14790
NOTE: because there could be different reasons for each one being in a waiting state, we should FIRST look for any
ImagePullBackOff
reasons and then only return all those as the state, then SECOND check forCrashLoopBackOff
so we present the most pressing issues to the user in the state first.The text was updated successfully, but these errors were encountered: