Uploaded image for project: 'OpenShift Console'
  1. OpenShift Console
  2. CONSOLE-2804

OLM UI Improvements for 4.9


    • OLM UI Improvements for 4.9
    • False
    • False
    • Done
    • OCPPLAN-8037 - OLM UI: Operator first-class experience
    • OCPPLAN-8037OLM UI: Operator first-class experience
    • 0% To Do, 0% In Progress, 100% Done
    • Undefined

      Epic Goal

      • OCP console supports devs to easier focus and create Operand/CR instances on the creation form page.
      • OCP console supports cluster admins to better see/understand the Operator installation status in the OperatorHub page.

      Why is this important?

      • OperatorHub page currently shows an Operator as Installed as long as a Subscription object exists for that operator in the current namespace, which can be misleading because the installation could be stalled or require additional interactions from the user (e.g. "manual upgrade approval") in order to complete the installation.
      • Some Operator managed services use these advanced properties in their CRD validation schema, but the current form generator in the console ignores/skips them. Hence, those fields on the creation form are missing.


      1. As a user of OperatorHub, I'd like to have an improved "status display" for Operators being installed before so I can better understand if those Operators actually being successfully installed or require additional actions from me to complete the installation.
      2. As a user of the OCP console, I'd like to Operand/CR creation form that covers advanced JSONSchema validation properties so I can create a CR instance solely with the form view.

      Acceptance Criteria

      • Console improves the visibility of Operator installation status on OperatorHub page
      • Console operand creation form adds support for `allOf`, `anyOf`, `oneOf`, and `additionalProperties` JSONSchema validation keywords so the creation form UI can render them and not skipping those properties/fields.
      • CI - MUST be running successfully with tests automated
      • Release Technical Enablement - Provide necessary release enablement details and documents.
      • ...

      Done Checklist

      • CI - CI is running, tests are automated and merged.
      • Release Enablement <link to Feature Enablement Presentation>
      • DEV - Upstream code and tests merged: <link to meaningful PR or GitHub Issue>
      • DEV - Upstream documentation merged: <link to meaningful PR or GitHub Issue>
      • DEV - Downstream build attached to advisory: <link to errata>
      • QE - Test plans in Polarion: <link or reference to Polarion>
      • QE - Automated tests merged: <link or reference to automated tests>
      • DOC - Downstream documentation merged: <link to meaningful PR>

      • Options


            spadgett@redhat.com Samuel Padgett
            rhn-coreos-tunwu Tony Wu
            Yanping Zhang Yanping Zhang
            0 Vote for this issue
            4 Start watching this issue