Bug 1701473 - Use correct and distinctive categories for different operators
Summary: Use correct and distinctive categories for different operators
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: OpenShift Container Platform
Classification: Red Hat
Component: OLM
Version: unspecified
Hardware: Unspecified
OS: Unspecified
low
low
Target Milestone: ---
: ---
Assignee: lgallett
QA Contact: Fan Jia
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2019-04-19 07:21 UTC by Yadan Pei
Modified: 2019-08-27 18:11 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2019-08-27 18:11:16 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)
RobinStorage Description (146.10 KB, image/png)
2019-04-19 07:21 UTC, Yadan Pei
no flags Details

Description Yadan Pei 2019-04-19 07:21:04 UTC
Created attachment 1556353 [details]
RobinStorage Description

Description of problem:
Use correct and distinctive categories for different operators, also we need update Description font for Robin Storage

Version-Release number of selected component (if applicable):
4.0.0-0.nightly-2019-04-18-190537
console commit: io.openshift.build.commit.id=8a2df3e00d50c88f630e329159e6bcd98f6b2767
io.openshift.build.commit.url=https://github.com/openshift/console/commit/8a2df3e00d50c88f630e329159e6bcd98f6b2767

How reproducible:
Always

Steps to Reproduce:
1. cluster admin logs into admin console and visit Catalog -> Operator Hub page
$ oc get packagemanifests robin-operator -n openshift-marketplace -o yaml | grep categories
        categories: Database,BigData,Storage
$ oc get packagemanifests spark-gcp  -n openshift-marketplace -o yaml | grep categories
        categories: Big Data

Actual results:
1. There are two similar Categories: Big Data and BigData, user can't view the differences between these categories

Expected results:
1. Use distinctive categories for different operator

Additional info:
This may need operator author to change the configurations and not console issue

Comment 1 Samuel Padgett 2019-04-19 16:54:59 UTC
Console is using the metadata from the package manifest. I think the best solution is to align the categories there.

Comment 2 Evan Cordell 2019-04-22 17:53:54 UTC
The PackageManifest is just passing through the annotations defined by OperatorHub. I couldn't track down the docs for the current set of Categories, so I'm moving this to the OperatorHub component

Comment 3 lgallett 2019-04-22 18:19:47 UTC
Accepted categories are listed here https://github.com/operator-framework/community-operators/blob/master/docs/required-fields.md#categories. I will create a PR to map the categories from packagemanifest to this set of categories. If none of the categories listed in the packagemanifest are on the above list, the operator will be categorized as "other" in the UI. Does that sound good?

Comment 4 lgallett 2019-04-22 18:31:51 UTC
Actually, this is an error with the CSV so I will submit PRs against the community-operators repo to fix these CSVs

Comment 5 Daniel Messer 2019-04-23 13:45:27 UTC
I think it would be worthwhile having an agreed list of categories in a file that multiple components can draw from to make validation. Long-term we should have a shared library that multiple components can use to determine the validity of an Operator and decide whether to display it or not.

Comment 6 Brian Cook 2019-04-23 19:48:58 UTC
operator-courier should know what the valid categories are and emit a linting error if the category is not valid.  Apparently it already does this with the validate-ui flag, but were asked to not use that flag since it was tuned for operatorhub.io.  We can enable using that flag for testing operators again, we can pull that test into the core set of linting tests, or we can add an additional flag specifically for embedded operatorhub.

Comment 7 Fan Jia 2019-05-07 03:37:35 UTC
The category of operator "AppDynamics ClusterAgent" is `Application Monitoring`, suggest it to be `Monitoring`; the category of "Tufin Orca Operator" if `Security Policy Management`, suggest it to be `Security`. And all the categories of our default opsrc should belong to the list of the recommand categories in https://github.com/operator-framework/community-operators/blob/master/docs/required-fields.md#categories.

Comment 9 Evan Cordell 2019-08-27 18:11:16 UTC
This should not be attached to a specific openshift release.

There is a process in community-operators for setting these categories.


Note You need to log in before you can comment on or make changes to this bug.