ImagePullBackOff should immediately flag a deployment as failed #863
Labels
Comments
edvald
added a commit
that referenced
this issue
Jun 21, 2019
This combines a general refactor of our workload status checks, more robust checking of related resource statuses (in order to fail fast on common errors like ImagePullBackOff and CrashLoopBackOff), as well as an improvement on the level of information given when errors do come up. This should aid considerably in debugging deployment issues. Closes #863
edvald
added a commit
that referenced
this issue
Jun 21, 2019
This combines a general refactor of our workload status checks, more robust checking of related resource statuses (in order to fail fast on common errors like ImagePullBackOff and CrashLoopBackOff), as well as an improvement on the level of information given when errors do come up. This should aid considerably in debugging deployment issues. Closes #863
edvald
added a commit
that referenced
this issue
Jun 24, 2019
This combines a general refactor of our workload status checks, more robust checking of related resource statuses (in order to fail fast on common errors like ImagePullBackOff and CrashLoopBackOff), as well as an improvement on the level of information given when errors do come up. This should aid considerably in debugging deployment issues. Closes #863
edvald
added a commit
that referenced
this issue
Jun 24, 2019
This combines a general refactor of our workload status checks, more robust checking of related resource statuses (in order to fail fast on common errors like ImagePullBackOff and CrashLoopBackOff), as well as an improvement on the level of information given when errors do come up. This should aid considerably in debugging deployment issues. Closes #863
thsig
pushed a commit
that referenced
this issue
Jun 24, 2019
This combines a general refactor of our workload status checks, more robust checking of related resource statuses (in order to fail fast on common errors like ImagePullBackOff and CrashLoopBackOff), as well as an improvement on the level of information given when errors do come up. This should aid considerably in debugging deployment issues. Closes #863
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Bug
Current Behavior
Currently, deployments hang for a while and eventually time out when the cluster is unable to fetch the image for a pod.
Expected behavior
I'd expect Garden to show an error as soon as an ImagePullBackoff event comes up in relation to the pods I'm deploying.
Reproducible example
Use any Helm chart that has a values parameter for
imagename and/or tag. Configure it witha dummy non-existing name/tag and try to run
garden deploy.Workaround
Make sure your image names/tags are correct, I guess.
Suggested solution(s)
We need to rework how we collect information about workload deployment status. We're missing or ignoring some relevant events.
Your environment
Latest master (any recent version really).
The text was updated successfully, but these errors were encountered: