Hide Forgot
Created attachment 1498583 [details] Cluster console Crashlooping Pod counter Description of problem: Crashlooping Pod number in Cluster console doesn't display the real value. It displays "0" instead of the real pod number value in "CrashLoopBackOff" state. Version-Release number of selected component (if applicable): Openshift 3.11 How reproducible: Create a new app, restart a pod may times so it becomes in Crahsloop state, and check Openshift Cluster Console. Instead of showing a Crashlooping value of "1", it always displays "0". Steps to Reproduce: 1. Create a new project test: oc new-project test 2. Create a new test app: oc new-project testoc new-app https://github.com/openshift/sti-ruby.git --context-dir=2.0/test/puma-test-app 3. Get POD Container ID: docker ps -a | grep ruby | grep ose-pod | grep Up 4. Kill POD Container ID with SIGTERM (I used SIGHUP): docker kill --signal=SIGHUP CONTAINER-ID 5. Repeat 3 and 4 until POD status changes to "CrashLoopBackOff" watch -n 5 "docker kill --signal=SIGHUP $(docker ps -a | grep ruby | grep ose-pod | grep Up | awk '{print $1}')" oc get pods | grep Crash 6. Check Cluster Console (make sure Project is the new one, "test") Actual results: Crashlooping Pods number in Cluster Console remains as "0" instead of "1" Expected results: Crashlooping Pods number in Cluster Console should be "1"
Fixed by https://github.com/openshift/console/pull/716
1. create dummy pods 2. check status on cluster console, Pods page and Home -> Status page Crashlooping Pods are NOT showing on Status page, recording in attachment
apiVersion: v1 kind: Pod metadata: name: dummy-pod spec: containers: - name: dummy-pod image: ubuntu restartPolicy: Always
Verify the bug on openshift v3.11.38
(In reply to Yadan Pei from comment #5) > 1. create dummy pods > > 2. check status on cluster console, Pods page and Home -> Status page > > Crashlooping Pods are NOT showing on Status page, recording in attachment We're querying Prometheus for pods with 5 container restarts within the last 5 minutes. It might take a few minutes to update (as you've found).
Thanks for the info Sam
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2018:3537