Bug 1751388 - Can't display more than two Update Channels on the 'Create Operator Subscription' page
Summary: Can't display more than two Update Channels on the 'Create Operator Subscript...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: OpenShift Container Platform
Classification: Red Hat
Component: OLM
Version: 4.1.z
Hardware: Unspecified
OS: Unspecified
unspecified
medium
Target Milestone: ---
: 4.1.z
Assignee: Evan Cordell
QA Contact: Bruno Andrade
URL:
Whiteboard:
Depends On: 1756109
Blocks:
TreeView+ depends on / blocked
 
Reported: 2019-09-11 21:28 UTC by Jason Montleon
Modified: 2019-10-16 18:08 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2019-10-16 18:07:59 UTC
Target Upstream Version:


Attachments (Terms of Use)
Screenshot showing only two of three specified update channels appearing in Console (332.26 KB, image/png)
2019-09-11 21:28 UTC, Jason Montleon
no flags Details


Links
System ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2019:3004 None None None 2019-10-16 18:08:08 UTC
Github operator-framework operator-registry pull 91 None None None 2019-09-30 19:03:58 UTC

Description Jason Montleon 2019-09-11 21:28:09 UTC
Created attachment 1614245 [details]
Screenshot showing only two of three specified update channels appearing in Console

Description of problem:
I am attempting to create an OLM package with three channels, but I can only ever see up to two in the UI when trying to install and add the subscription.

Version-Release number of selected component (if applicable):
OpenShift 4.1.14

How reproducible:
Seems always

Steps to Reproduce:
1. Create an OLM application package with 3 channels
2. Upload the Application to Quay
3. Install the operator source in Openshift
4. Try to add the subscription in Openshift Web UI

Actual results:
Two out of three channels show up as options

Expected results:
Any channels in the package are visible.

Additional info:
I am modifying https://github.com/fusor/mig-operator/blob/master/deploy/olm-catalog/mig-operator/0.0.1/mig-operator.package.yaml to look like so:

packageName: mig-operator
channels:
- name: release-1.0
  currentCSV: mig-operator.1.0
- name: stable
  currentCSV: mig-operator.stable
- name: latest
  currentCSV: mig-operator.latest

I have created copies of the CSV with corresponding file names/names in the YAML and adjusted the operator images each deploys. As far as I can tell if I reduce the channels to any two they show up correctly, but as soon as I add a third only two display.

Comment 1 Jason Montleon 2019-09-12 14:30:28 UTC
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.

Comment 2 Jason Montleon 2019-09-24 15:06:44 UTC
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@redhat.com"

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.

Comment 3 Erik Nelson 2019-09-24 15:32:54 UTC
+1, I can confirm I independently am seeing the same thing. I'm only seeing "alpha" and a "release" channel.

Comment 4 Samuel Padgett 2019-09-24 15:57:13 UTC
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?

Comment 5 Erik Nelson 2019-09-24 16:49:07 UTC
@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.

Comment 6 Samuel Padgett 2019-09-24 16:52:26 UTC
Changing the component to OLM based on comment #5. If this turns out to be a console bug, feel free to send it back.

Comment 7 Jason Montleon 2019-09-24 16:59:53 UTC
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

Comment 8 Erik Nelson 2019-09-24 18:01:37 UTC
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"
    }
  ]
}

Comment 9 Erik Nelson 2019-09-24 18:50:54 UTC
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.

Comment 10 Jason Montleon 2019-09-24 18:51:47 UTC
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"
    }
  ]
}

Comment 14 Bruno Andrade 2019-10-08 03:05:56 UTC
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@redhat.com"
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

Comment 16 errata-xmlrpc 2019-10-16 18:07:59 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-2019:3004


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