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

Support for new operator annotations format 4.16

XMLWordPrintable

    • Icon: Epic Epic
    • Resolution: Unresolved
    • Icon: Normal Normal
    • openshift-4.16
    • None
    • None
    • Support for new operator annotations format 4.16
    • False
    • None
    • False
    • Not Selected
    • To Do
    • OCPSTRAT-962 - OCP Console support for short-lived token enablement of OLM-managed operators using GCP WIF
    • OCPSTRAT-962OCP Console support for short-lived token enablement of OLM-managed operators using GCP WIF
    • 0% To Do, 0% In Progress, 100% Done

      Epic Goal

      • Transparently support old and new infrastructure annotations format delivered by OLM-packaged operators

      Why is this important?

      • As part of part of OCPSTRAT-288 we are looking to improve the metadata quality of Red Hat operators in OpenShift
      • via PORTENABLE-525 we are defining a new metadata format that supports the aforementioned initiative with more robust detection of individual infrastructure features via boolean data types

      Scenarios

      1. A user can use the OCP console to browse through the OperatorHub catalog and filter for all the existing and new annotations defined in PORTENABLE-525
      2. A user reviewing an operator's detail can see the supported infrastructures transparently regardless if the operator uses the new or the existing annotations format

      Acceptance Criteria

      • the new annotation format is supported in operatorhub filtering and operator details pages
      • the old annotation format keeps being supported in operatorhub filtering and operator details pages
      • the console will respect both the old and the new annotations format
      • when for a particular feature both the operator denotes data in both the old and new annotation format, the annotations in the newer format take precedence
      • the newer infrastructure features from PORTENABLE-525 tls-profiles and token-auth/* do not have equivalents in the old annotation format and evaluation doesn't need to fall back as described in the previous point

      Dependencies (internal and external)

      1. none

      Open Questions

      1. due to the non-intrusive nature of this feature, can we ship it in a 4.14.z patch release?

      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>

              Unassigned Unassigned
              DanielMesser Daniel Messer
              Xiyun Zhao Xiyun Zhao
              Votes:
              0 Vote for this issue
              Watchers:
              2 Start watching this issue

                Created:
                Updated: