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

OLM UI Improvements for 4.9

XMLWordPrintable

    • 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.

      Scenarios

      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
              Votes:
              0 Vote for this issue
              Watchers:
              4 Start watching this issue

                Created:
                Updated:
                Resolved: