Uploaded image for project: 'OpenShift Container Platform (OCP) Strategy'
  1. OpenShift Container Platform (OCP) Strategy
  2. OCPSTRAT-798

New Infrastructure Capabilities annotations


    • Icon: Feature Feature
    • Resolution: Done
    • Icon: Normal Normal
    • None
    • None
    • Core
    • None
    • False
    • Hide


    • False
    • OCPSTRAT-288Improve the operator catalog user experience
    • 0% To Do, 0% In Progress, 100% Done
    • 0
    • 0
    • Program Call

      Feature Overview (aka. Goal Summary)  

      Customers can trust the metadata in our operators catalogs to reason about infrastructure compatibility and interoperability. Similar to OCPPLAN-7983 the requirement is that this data is present for every layered product and Red Hat-release operator and ideally also ISV operators.

      Today it is hard to validate the presence of this data due to the metadata format. This features tracks introducing a new format, implementing the appropriate validation and enforcement of presence as well as defining a grace period in which both formats are acceptable.

      Goals (aka. expected user outcomes)

      Customers can rely on the operator metadata as the single source of truth for capability and interoperability information instead of having to look up product-specific documentation. They can use this data to filter in on-cluster and public catalog displays as well as in their pipelines or custom workflows.

      Red Hat Operators are required to provide this data and we aim for near 100% coverage in our catalogs.

      Absence of this data can reliably be detected and will subsequently lead to gating in the release process.

      Requirements (aka. Acceptance Criteria):

      • discrete annotations per feature that can be checked for presence as well as positive and negative values (see PORTEANBLE-525)
      • support in the OCP console and RHEC to support both the new and the older metadata annotations format
      • enforcement in ISV and RHT operator release pipelines
        • first with non-fatal warnings
        • later with blocking behavior if annotations are missing
        • the presence of ALL annotations needs to be checked in all pipelines / catalogs

      Questions to Answer:

      • when can we rollout the pipeline tests?
        • only when there is support for visualization in the OCP Console and catalog.redhat.com
      • should operator authors use both, old and new annotations at the same time?
        • they can, but there is no requirement to do that, once the support in console and RHEC is there, the pipelines will only check for the new annotations
      • what happens to older OCP releases that don't support the new annotations yet?
        • the only piece in OCP that is aware of the annotations is the console, and we plan to backport the changes all the way to 4.10


      Customer Considerations

      Provide any additional customer-specific considerations that must be made when designing and delivering the Feature.  Initial completion during Refinement status.


      Documentation Considerations

      • we first need internal documentation for RHT and ISV teams that need to implement the change
      • when RHEC and Console are ready, we will update the external documentation and and can point to that as the official source of truth


      Interoperability Considerations

      • OCP Console will have to support the new format (see CONSOLE-3688) in parallel to the old format (as fallback) in all currently supported OCP versions

            DanielMesser Daniel Messer
            DanielMesser Daniel Messer
            Ashley Hardin Ashley Hardin
            0 Vote for this issue
            4 Start watching this issue