Description of problem: In the console, the Project Status screen shows the total count of pods, regardless of which are available and unavailable. For example, I scaled up my service from 1 to 3. The Project Status quickly reflected "3 of 3". Clicking the arrow next to it reflected that 1 was available and 2 were unavailable (they were still in ContainerCreating). This makes the count without those details misleading that the service is completely functioning. Version-Release number of selected component (if applicable): Image: quay.io/openshift-release-dev/ocp-release@sha256:5b7d1c80f75a7703b5622de7273d63b4939dbfae1986b87b3fee436a1dacab44 Started Time: 2019-02-07T21:03:10Z State: Completed Version: 4.0.0-0.3 How reproducible: 100% Steps to Reproduce: 1. Deploy an existing image. 2. Keep an eye on the Project Status screen of the web UI. The count will reflect "1 of 1" while the container is still being created. Clicking the arrow will show that the pod is listed as unavailable. Actual results: Expected results: Additional info:
This is currently working as intended, although I understand the usability issue. It's not possible to convey both count and readiness in one number. If we only show ready pods, it's arguably misleading as well because the total count is wrong. The way we addressed this previously was using the pod donut, which conveyed readiness as a different arc in the donut. We have RFEs in our backlog to add this back.
We've added the pod donut back in 4.2. This is visible in the details sidebar on the overview and indicates when pods are not ready. https://github.com/openshift/console/pull/2091
1. Create app from Deploy Image 2. Go to Projects -> Workloads, It will show count 1 of 1 pods, clicking on the banner will open sidebar, there is pod donut showing pod status, Pending, Running, Terminating... The number "N of N pods" reflects the replicas of resources, while the pod donut shows the pods status which gives user a clear status of application status Verified on 4.2.0-0.nightly-2019-08-28-152644
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-2019:2922