I'm not sure this is a console bug looking further.

When I run oc export PackageManifest -n openshift-marketplace mig-operator I only see two CSV's.

Modifying operator-courier a bit so I can see the bundle.yaml that is generated all three CSV's are present in the file. 

It seems like somewhere along the way from upload to Quay and processing into a PackageManifest one is being dropped for some reason.

My operatorsource is configured to point at an application with 3 channels:

apiVersion: operators.coreos.com/v1
kind: OperatorSource
metadata:
  name: ocpmigrate-operators
  namespace: openshift-marketplace
spec:
  type: appregistry
  endpoint: https://quay.io/cnr
  registryNamespace: jmontleon
  displayName: "Migration Operators"
  publisher: "ocp-migrate-team"

When I run grpcurl inside the openshift-marketplace app-registry container for this source I only get two channels:

/tmp/grpcurl -plaintext -d '{ "name": "mig-operator" }'  localhost:50051 api.Registry/GetPackage
{
  "name": "mig-operator",
  "channels": [
    {
      "name": "alpha",
      "csvName": "mig-operator.3.0.0"
    },
    {
      "name": "release-v1",
      "csvName": "mig-operator.1.0.0"
    }
  ]
}

Looking at bundles.db on the container I see:
[jmontleo@jmontleo Desktop]$ sqlite3 bundles.db 
SQLite version 3.26.0 2018-12-01 12:34:55
Enter ".help" for usage hints.
sqlite> SELECT * FROM channel;
alpha|mig-operator|mig-operator.3.0.0
stable|mig-operator|mig-operator.2.0.0
release-v1|mig-operator|mig-operator.1.0.0
sqlite> SELECT * FROM package;
mig-operator|
sqlite> .tables
api             channel         operatorbundle
api_provider    channel_entry   package       
sqlite> SELECT * FROM channel_entry;
1|alpha|mig-operator|mig-operator.3.0.0||0
2|stable|mig-operator|mig-operator.2.0.0||0
3|release-v1|mig-operator|mig-operator.1.0.0||0

SELECT * FROM operatorbundle; also shows all three although the output is more than should be pasted in a comment. If it would be helpful I can create another attachment.

+1, I can confirm I independently am seeing the same thing. I'm only seeing "alpha" and a "release" channel.

The UI is showing the values from `status.channels` in the PackageManifest resource. Can you check the PackageManifest to see if the values match what's in the UI?

@Sam, I'm trying to confirm on a more recent cluster (4.1.16). I don't think this is a UI bug since the grpc query only returns two channels. It seems like something is wrong with the registry-server. The database contains the 3 channels as expected, but the registry-server is only reporting the two.

Changing the component to OLM based on comment #5. If this turns out to be a console bug, feel free to send it back.

Hi Sam,
In comment 1 I mentioned I'm pretty sure this is not a UI bug after doing some digging.

There seems to be a difference on the appregistry-server pod for the operator source between what exists in hte DB and what's being returned in the grpc response and so I wouldn't expect the UI to show what doesn't exist in that response.

We've either done something improper or there's a bug in the appregistry-server

The output you requested should just confirm that:
oc get PackageManifest -n openshift-marketplace mig-operator -o go-template='{{ range $key, $value := .status.channels }}{{ println $value.currentCSV }}{{ end}}'
mig-operator.3.0.0
mig-operator.1.0.0

Confirmed on my 4.1.16 cluster, here's the output querying the package:

sqlite> SELECT DISTINCT package.name, default_channel, channel.name, channel.head_operatorbundle_name
   ...>               FROM package INNER JOIN channel ON channel.package_name=package.name
   ...>               WHERE package.name='mig-operator'
   ...> ;
mig-operator||alpha|mig-operator.1.1.1
mig-operator||release-v1|mig-operator.1.0.0
mig-operator||stable|mig-operator.1.1.0

Here's the grpc output:

bash-4.2$ ./grpcurl -plaintext -d '{ "name": "mig-operator" }'  localhost:50051 api.Registry/GetPackage
{
  "name": "mig-operator",
  "channels": [
    {
      "name": "alpha",
      "csvName": "mig-operator.1.1.1"
    },
    {
      "name": "release-v1",
      "csvName": "mig-operator.1.0.0"
    }
  ]
}

I built and tested an image from https://github.com/operator-framework/operator-registry, branch "release-4.1" and saw the unexpected above behavior.

Then, using the same manifests, I built and tested the "release-4.2" branch, and saw the expected output:

# grpcurl -plaintext -d '{"name":"mig-operator"}' localhost:50051 api.Registry/GetPackage
{
  "name": "mig-operator",
  "channels": [
    {
      "name": "alpha",
      "csvName": "mig-operator.1.1.1"
    },
    {
      "name": "release-v1",
      "csvName": "mig-operator.1.0.0"
    },
    {
      "name": "stable",
      "csvName": "mig-operator.1.1.0"
    }
  ],
  "defaultChannelName": "release-v1"
}

Looks like this is a bug in the release-4.1 branch that has been fixed in release-4.2.

I think this is a bug in the 4.1 branch. I see the results I expect from the 4.2/master branches.

grpcurl -plaintext -d '{ "name": "mig-operator" }'  localhost:50051 api.Registry/GetPackage
{
  "name": "mig-operator",
  "channels": [
    {
      "name": "alpha",
      "csvName": "mig-operator.3.0.0"
    },
    {
      "name": "release-v1",
      "csvName": "mig-operator.1.0.0"
    },
    {
      "name": "stable",
      "csvName": "mig-operator.2.0.0"
    }
  ]
}

Three channels are shown as expected, marking as VERIFIED.

Cluster Version: 4.1.0-0.nightly-2019-10-07-204516
OLM version: 0.9.0
git commit: d7e24eecd1da1a90d01d4a4ea8403217c77c84fa


Steps used to reproduce:

1. Install the OperatorSource with a package containing 3 channels
oc apply -f - <<EOF
apiVersion: operators.coreos.com/v1
kind: OperatorSource
metadata:
  name: ocpmigrate-operators
  namespace: openshift-marketplace
spec:
  type: appregistry
  endpoint: https://quay.io/cnr
  registryNamespace: jmontleon
  displayName: "Migration Operators"
  publisher: "ocp-migrate-team"
EOF

2. Try to add the subscription to Openshift Web UI. Three channels are shown as expected: http://pics.osci.redhat.com/fqlrof.png

3. Check if the operator is successfully installed:

oc get csv -n default
NAME                  DISPLAY              VERSION   REPLACES   PHASE
mig-operator.stable   Migration Operator   1.0.0                Succeeded


oc get pods -n default
AME                                  READY   STATUS    RESTARTS   AGE
migration-operator-55444b58dc-wpn6q   2/2     Running   0          6m55

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:3004