Bug 1683045

sometimes can't load the `Catalog->Operator Management` page when the project is "openshif-operators" or "all-namespaces"
url link
`https://console-openshift-console.apps.zzhaomu.qe.devcluster.openshift.com/operatormanagement/ns/openshift-operators`

error of js:
`Failed to load resource: the server responded with a status of 404 (Not Found)`
`Failed to load resource: the server responded with a status of 503 (Service Unavailable)`
`react-dom.production.min.js:13 TypeError: Cannot read property 'filter' of undefined
    at features.ts:46
    at features.ts:46
    at Array.some (<anonymous>)
    at Row (features.ts:46)
    at beginWork (react-dom.production.min.js:13)
    at o (react-dom.production.min.js:13)
    at a (react-dom.production.min.js:13)
    at C (react-dom.production.min.js:13)
    at _ (react-dom.production.min.js:13)
    at b (react-dom.production.min.js:13)
`

Need the output of `kubectl get catalogsources -n openshift-marketplace -o yaml`.

I can confirm that this not happen with the operators from default OperatorSources. Given that, this is not a beta blocker.

(In reply to Alec Merdler from comment #2)
> Need the output of `kubectl get catalogsources -n openshift-marketplace -o
> yaml`.

apiVersion: v1
items:
- apiVersion: operators.coreos.com/v1alpha1
  kind: CatalogSource
  metadata:
    creationTimestamp: 2019-02-26T15:01:17Z
    generation: 1
    labels:
      olm-visibility: hidden
      openshift-marketplace: "true"
      opsrc-datastore: "true"
      opsrc-provider: certified
    name: certified-operators
    namespace: openshift-marketplace
    ownerReferences:
    - apiVersion: marketplace.redhat.com/v1alpha1
      blockOwnerDeletion: true
      controller: true
      kind: CatalogSourceConfig
      name: certified-operators
      uid: 5db31379-39d7-11e9-9a84-06791ad62ede
    resourceVersion: "14809"
    selfLink: /apis/operators.coreos.com/v1alpha1/namespaces/openshift-marketplace/catalogsources/certified-operators
    uid: 5e25afc7-39d7-11e9-9a84-06791ad62ede
  spec:
    address: 172.30.73.214:50051
    displayName: Certified Operators
    icon:
      base64data: ""
      mediatype: ""
    publisher: Red Hat
    sourceType: grpc
  status:
    lastSync: 2019-02-26T15:03:56Z
    registryService:
      createdAt: 2019-02-26T15:03:56Z
      protocol: grpc
- apiVersion: operators.coreos.com/v1alpha1
  kind: CatalogSource
  metadata:
    creationTimestamp: 2019-02-26T17:11:19Z
    generation: 1
    labels:
      olm-visibility: hidden
      openshift-marketplace: "true"
      opsrc-datastore: "true"
      opsrc-provider: community
    name: community-operators
    namespace: openshift-marketplace
    ownerReferences:
    - apiVersion: marketplace.redhat.com/v1alpha1
      blockOwnerDeletion: true
      controller: true
      kind: CatalogSourceConfig
      name: community-operators
      uid: 88c6c2cc-39e9-11e9-8f18-02b700d63364
    resourceVersion: "99092"
    selfLink: /apis/operators.coreos.com/v1alpha1/namespaces/openshift-marketplace/catalogsources/community-operators
    uid: 88e9beab-39e9-11e9-8f18-02b700d63364
  spec:
    address: 172.30.192.81:50051
    displayName: Community Operators
    icon:
      base64data: ""
      mediatype: ""
    publisher: Red Hat
    sourceType: grpc
  status:
    lastSync: 2019-02-26T17:12:20Z
    registryService:
      createdAt: 2019-02-26T17:12:20Z
      protocol: grpc
- apiVersion: operators.coreos.com/v1alpha1
  kind: CatalogSource
  metadata:
    creationTimestamp: 2019-02-26T19:08:43Z
    generation: 1
    labels:
      olm-visibility: hidden
      openshift-marketplace: "true"
      opsrc-datastore: "true"
      opsrc-provider: dddd
    name: kakatest
    namespace: openshift-marketplace
    ownerReferences:
    - apiVersion: marketplace.redhat.com/v1alpha1
      blockOwnerDeletion: true
      controller: true
      kind: CatalogSourceConfig
      name: kakatest
      uid: eed8e030-39f9-11e9-892e-02b700d63364
    resourceVersion: "176911"
    selfLink: /apis/operators.coreos.com/v1alpha1/namespaces/openshift-marketplace/catalogsources/kakatest
    uid: eefa1a86-39f9-11e9-892e-02b700d63364
  spec:
    address: 172.30.129.109:50051
    displayName: dddd
    icon:
      base64data: ""
      mediatype: ""
    publisher: dddd
    sourceType: grpc
  status:
    lastSync: 2019-02-26T19:08:58Z
    registryService:
      createdAt: 2019-02-26T19:08:58Z
      protocol: grpc
- apiVersion: operators.coreos.com/v1alpha1
  kind: CatalogSource
  metadata:
    creationTimestamp: 2019-02-26T15:01:18Z
    generation: 1
    labels:
      olm-visibility: hidden
      openshift-marketplace: "true"
      opsrc-datastore: "true"
      opsrc-provider: redhat
    name: redhat-operators
    namespace: openshift-marketplace
    ownerReferences:
    - apiVersion: marketplace.redhat.com/v1alpha1
      blockOwnerDeletion: true
      controller: true
      kind: CatalogSourceConfig
      name: redhat-operators
      uid: 5dbe2c6e-39d7-11e9-9a84-06791ad62ede
    resourceVersion: "14907"
    selfLink: /apis/operators.coreos.com/v1alpha1/namespaces/openshift-marketplace/catalogsources/redhat-operators
    uid: 5edb306e-39d7-11e9-9a84-06791ad62ede
  spec:
    address: 172.30.207.120:50051
    displayName: Red Hat Operators
    icon:
      base64data: ""
      mediatype: ""
    publisher: Red Hat
    sourceType: grpc
  status:
    lastSync: 2019-02-26T15:03:58Z
    registryService:
      createdAt: 2019-02-26T15:03:58Z
      protocol: grpc
kind: List
metadata:
  resourceVersion: ""
  selfLink: ""

This must be some issue with the registry pod that the Marketplace Operator is spinning up from the App Registry source. The JS error is being thrown because of missing fields on the `PackageManifest` (`installModes`). We clearly need more validation before we start the gRPC server.

Fan Jia, for now please validate what you are pushing to Quay before using it in your tests. Please follow these (https://github.com/operator-framework/operator-lifecycle-manager/blob/master/Documentation/design/building-your-csv.md and https://github.com/operator-framework/community-operators/blob/master/docs/required-fields.md) guides when constructing your custom CSVs. You should also follow the guidelines here (https://github.com/operator-framework/community-operators/blob/master/docs/testing-operators.md#testing-operators) for pushing to Quay.

We plan on adding better validation for 4.2.

testenv:
cv:4.0.0-0.nightly-2019-02-26-125216

test pass if change the package follow all the guides.

If the operators in the `operator hub` from "custom" provider has the same name as the operators that exist in the "pre-installed" operators. Then the `subscription` page can load normally. The page can't load only if the package's name is different. 
for eg:
1. push an operator `descheduler` to the quay's ns "kaka", the package name is `descheduler`.
2. create an operatorsource by the quay ns kaka 
3. and the `descheduler` operator will be loaded on the operator hub's UI, click the install button on the detail page of this operator `descheduler`. the `subscription page` can be loaded
4. update the operator `descheduler`'s package name to `descheduler-test`,and push it to quay ns "kaka", reload it to the ocp cluster again
5. the operaor `descheduler` 's  package name is changed to `descheduler-test` ,and if click the install button on the detail page of this operator `descheduler` . the `subscription page` can't be loaded

Fan Jia, please provide your OperatorSource so that we can try to reproduce this.

(In reply to Fan Jia from comment #10)
> (In reply to aravindh from comment #9)
> > Fan Jia, please provide your OperatorSource so that we can try to reproduce
> > this.
> 
> aravindh, I have found the root cause about this problem. The page crash
> because the packagemanifest doesn't have the `Install Mode` config. So I can
> install the operator by CLI but can't use it by UI since the UI need this
> parameter. And the add the same name operators of "pre-install" operators
> ,the packagemanifest will only get the "first" operator and it own the
> "Install Mode". I think we should create one bug or story about how to deal
> with the `same name` operators in operator hub.

And I think the marketplace should check the "Install Mode" parameter should exist in the operatos from the custom's registory. I will create a new bug to track that.

(In reply to Fan Jia from comment #11)
> (In reply to Fan Jia from comment #10)
> > (In reply to aravindh from comment #9)
> > > Fan Jia, please provide your OperatorSource so that we can try to reproduce
> > > this.
> > 
> > aravindh, I have found the root cause about this problem. The page crash
> > because the packagemanifest doesn't have the `Install Mode` config. So I can
> > install the operator by CLI but can't use it by UI since the UI need this
> > parameter. And the add the same name operators of "pre-install" operators
> > ,the packagemanifest will only get the "first" operator and it own the
> > "Install Mode". I think we should create one bug or story about how to deal
> > with the `same name` operators in operator hub.
>

Fan Jia, this is a known limitation of the Marketplace operator. Removing this limitation would involve some amount of re-architecting our data store. We plan to fix this for 4.2
 
> And I think the marketplace should check the "Install Mode" parameter should
> exist in the operatos from the custom's registory. I will create a new bug
> to track that.

This sort of checking should be added to either "operator-courier" or to "operator-registry" and not the marketplace.

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-2019:0758