Bug 1796078 - OLM Operators on the OperatorHub page should be filtered by GOOS and GOARCH (openshift-4.5)
Summary: OLM Operators on the OperatorHub page should be filtered by GOOS and GOARCH (...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: OpenShift Container Platform
Classification: Red Hat
Component: Management Console
Version: 4.4
Hardware: Unspecified
OS: Unspecified
unspecified
high
Target Milestone: ---
: 4.5.0
Assignee: Jakub Hadvig
QA Contact: Yadan Pei
URL:
Whiteboard:
: 1766278 (view as bug list)
Depends On:
Blocks: 1796080 1804851
TreeView+ depends on / blocked
 
Reported: 2020-01-29 14:45 UTC by bpeterse
Modified: 2020-07-13 17:13 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
: 1796079 1804851 (view as bug list)
Environment:
Last Closed: 2020-07-13 17:13:32 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Github openshift console pull 3887 0 None closed Bug 1796078: Filter OLM operators by architecture 2020-09-25 12:17:15 UTC
Red Hat Product Errata RHBA-2020:2409 0 None None None 2020-07-13 17:13:55 UTC

Description bpeterse 2020-01-29 14:45:07 UTC
Description of problem:

Not all operators support all architectures.  Therefore, operators under OLM will have an annotation defining supported architectures. If the current architecture of the cluster is not listed in this annotation, the console should filter (hide) the operator from view.  

* The console backend needs to use golang's sys/runtime library to get the architecture of the cluster/pod
* The console should pass the architecture to the front end
* The OLM page should filter based on the provided architecture data.  

This story supports https://issues.redhat.com/browse/OLM-1464

The backend work to gather the architecture & pass to the front end needs backports to 4.3 & 4.2
The front end filtering work needs backports to 4.3, 4.2 if it is clean.

Comment 3 Yadan Pei 2020-03-12 10:03:32 UTC
1. create custom catalog source, it references an image in which operator CSV has label 
  labels:
    operatorframework.io/os.windows: supported

# cat yapei-oswindows-catalog-source.yaml 
apiVersion: operators.coreos.com/v1alpha1
kind: CatalogSource
metadata:
  name: oswindows-keycloak-operators
  namespace: openshift-marketplace
spec:
  sourceType: grpc
  image: quay.io/yapei/keycloak-operator:oswindows
  displayName: windows label keycloak operator
  publisher: yapei

# oc create -f yapei-oswindows-catalog-source.yaml
catalogsource.operators.coreos.com/oswindows-keycloak-operators created

# oc get packagemanifests | grep keycloak
keycloak-operator                            Community Operators               8h
keycloak-operator                            windows label keycloak operator   43s

# oc get packagemanifests keycloak-operator --show-labels
NAME                CATALOG                           AGE   LABELS
keycloak-operator   windows label keycloak operator   56s   catalog-namespace=openshift-marketplace,catalog=oswindows-keycloak-operators,operatorframework.io/arch.amd64=supported,operatorframework.io/os.windows=supported,provider-url=,provider=Red Hat

2. cluster admin user view Operator Hub, search using keyword `keycloak` we can only see one operator item from community, also there is no Custom provider type


Verified on     4.5.0-0.nightly-2020-03-11-214319

Comment 4 Andy McCrae 2020-04-24 14:13:25 UTC
*** Bug 1766278 has been marked as a duplicate of this bug. ***

Comment 7 errata-xmlrpc 2020-07-13 17:13:32 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2020:2409


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