You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Looking at the terminated state of a container is not reliable as this
state does not last very long. Once a workload container exits
(regardless of the exit code) consistently, k8s puts the container into
`Waiting` state with reason `CrashLoopBackOff` until the scheduler
starts it again. As this is an exponential backoff, this state tends to
last longer and longer if the app keeps crashing.
With the previous implementation of looking at the `Terminated` state we
could never see the instance as `crashed` in the `cf app` output when we
intentionally kept crashing it.
Issue: #3082
Co-authored-by: Danail Branekov <danailster@gmail.com>
Looking at the terminated state of a container is not reliable as this
state does not last very long. Once a workload container exits
(regardless of the exit code) consistently, k8s puts the container into
`Waiting` state with reason `CrashLoopBackOff` until the scheduler
starts it again. As this is an exponential backoff, this state tends to
last longer and longer if the app keeps crashing.
With the previous implementation of looking at the `Terminated` state we
could never see the instance as `crashed` in the `cf app` output when we
intentionally kept crashing it.
Issue: #3082
Co-authored-by: Danail Branekov <danailster@gmail.com>
Acceptance
GIVEN I have pushed a crashing app
WHEN I get the app via
cf app my-app
THEN I eventually see the state of the app as
crashed
The text was updated successfully, but these errors were encountered: