Uploaded image for project: 'OpenShift Over the Air'
  1. OpenShift Over the Air
  2. OTA-1155

status: simplify operator status line


    • Icon: Story Story
    • Resolution: Done
    • Icon: Normal Normal
    • None
    • None
    • None
    • OTA 249, OTA 250, OTA 251, OTA 252

      Current state

      = Control Plane =
      Operator Status: 33 Total, 31 Available, 1 Progressing, 4 Degraded

      Improvement opportunities

      1. "33 Total" confuses people into thinking this number is a sum of the others (e.g. OCPBUGS-24643)
      2. "Available" is useless most of the time: in happy path it equals total, in error path the "unavailable" would be more useful, we should not require the user to do a mental subtraction when we can just tell them
      3. "1 Progressing" does not mean much, I think we can relay similar information by saying "1 upgrading" on the completion line (see OTA-1153)
      4. "0 degraded" is not useful (and 0 unavailable would be too), we can hide it on happy path
      5. somehow relay that operators can be both unavailable and degraded

      Definition of Done

      // Happy path, all is well
      Operator status: 33 Healthy
      // Two operators Available=False
      Operator status: 31 Healthy, 2 Unavailable
      // Two operators Available=False, one degraded
      Operator status: 30 Healthy, 2 Unavailable, 1 Available but degraded
      // Two operators Available=False, one degraded, one both => unavailable trumps degraded
      Operator status: 29 Healthy, 3 Unavailable, 1 Available but degraded

      Open questions

      1. How to handle COs briefly unavailable / degraded? OTA-1087 PoC does not show insights about them if they are briefly down / degraded to avoid noise, so we can either be inconsistent between counts and health, or between "adm status" and "get co". => extracted to OTA-1175

            dhurta@redhat.com David Hurta
            afri@afri.cz Petr Muller
            Petr Muller
            0 Vote for this issue
            3 Start watching this issue