Feature Overview (aka. Goal Summary)

Users leveraging the OperatorHub catalog UI are presented with groups of operators collapsed together under a common product or platform name.

Goals (aka. expected user outcomes)

Users have an easier time discovering products that consists of groups of operators or collections of operators that aim at a common platform (e.g. cloud service). It reduces visual space to display the catalog content and creates clarity about the relationship of of operators among each other.

Requirements (aka. Acceptance Criteria):

• OperatorHub UI gets a grouping concept where collections of operators are displayed under a common group name with the group being collapsed by default but able to be expanded to see all operators part of that group
• OperatorHub UI search auto-expands groups with matches for the search term
• Tooling the defines group constructs and related metadata (mainly human readable display name) which can be interpreted on cluster by the Console

Use Cases (Optional):

• a group called "Advanced Cluster Management" which would contain:
  • advanced-cluster-management
  • multicluster-global-hub-operator-product
  • multicluster-engine
  • submariner
  • gatekeeper-operator-product
  • volsync-product
  • klusterlet-product
• a group called Red Hat Quay which would contain:
  • quay-operator
  • quay-bridge-operator
  • container-security-operator
• a group called "AWS Operators" which would contain the entire collection of ACK controllers we currently publish in the community catalog

Questions to Answer (Optional):

Out of Scope

• an actual first class operator group concept in OLM, similar to rpm groups in dnf

Background

We have a lot of operators that are strongly related to each other, either at the product level or at the use case level that are scattered around the catalog due to alphabetical sort order. It's hard to find them as a result and the entirely flat nature of the catalog tile display contributes a lot to visual noise.

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

Provide information that needs to be considered and planned so that documentation will meet customer needs. If the feature extends existing functionality, provide a link to its current documentation. Initial completion during Refinement status.

Interoperability Considerations

Which other projects, including ROSA/OSD/ARO, and versions in our portfolio does this feature impact? What interoperability test scenarios should be factored by the layered products? Initial completion during Refinement status.