Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 1767070

Summary: Conflicting bundles from two operator sources
Product: OpenShift Container Platform Reporter: Ryan Hallisey <rhallise>
Component: Management ConsoleAssignee: bpeterse
Status: CLOSED DUPLICATE QA Contact: Yadan Pei <yapei>
Severity: medium Docs Contact:
Priority: medium    
Version: 4.2.0CC: aos-bugs, bsong, jokerman, krizza, nhale, nmukherj, spadgett, stirabos
Target Milestone: ---   
Target Release: 4.4.0   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2020-02-05 17:55:25 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
CNV in operatorHub
none
CNV subscription to channel 2.2 none

Description Ryan Hallisey 2019-10-30 15:54:45 UTC
Description of problem:

During testing of a OLM bundled application, I create an operator source that points at a registry containing the bundle I want to test.  I'm able to create the operator source, which gets me a catalog and a package manifest with my bundle.

The problem comes in when the bundle I just added to my cluster already exists from a different source.  In this example, I published an operator through Red Hat's pipeline so now it appears by default on all OpenShift installs.  So when I go back to work on subsequent updates, I conflicts between two package manifests during testing.

This is easily illustrated in the UI and CLI.  If you run the same command twice you'll get different results.

oc get packagemanifest kubevirt-hyperconverged

<2.0 package data> 

oc get packagemanifest kubevirt-hyperconverged

<2.1 package data> 


The UI is the same.  From the operatorhub tab, I click on the icon, click 'install', and the subscription could be for either 2.0 or 2.1.


Is there a way to associate a package manifest to an operator source?  Similar to the way a community operator is labeled?  Having some association between the objects would allow for testing to be easier and it would allow for customers to be able to "roll their own" copy of a Red Hat operator without having conflicts.

Comment 3 Ryan Hallisey 2019-11-05 10:57:28 UTC
There ends up being 3 package manifests created with the same name.  One is published in production, one in the community, and the last one is a new version I want to test.

[cnv-qe-jenkins@cnv-executor-alexxa-bz ~]$ oc get packagemanifest | grep virt
myvirtualdirectory                           Community Operators         8h
kubevirt-hyperconverged                      Red Hat Operators           13m
kubevirt-hyperconverged                      KubeVirt HyperConverged     13m
kubevirt-hyperconverged                      Community Operators         13m

Comment 8 Kevin Rizza 2019-11-20 13:26:06 UTC
FYI this is not a bug, this is a feature request. Currently the OperatorHub in the OpenShift console has no concept of targeting specific catalogs when creating subscriptions. I believe there is some work in progress that is being scoped out for this, but it is currently not available. IMO we should close this as NOTABUG.

Comment 14 Simone Tiraboschi 2020-01-31 16:42:17 UTC
Created attachment 1656735 [details]
CNV in operatorHub

Comment 15 Simone Tiraboschi 2020-01-31 16:42:49 UTC
Created attachment 1656737 [details]
CNV subscription to channel 2.2

Comment 16 Samuel Padgett 2020-01-31 19:15:12 UTC
The UI is meant to show the default channel:

https://github.com/openshift/console/blob/master/frontend/packages/operator-lifecycle-manager/src/components/operator-hub/operator-hub-page.tsx#L36-L53

Can you attach the full package manifest?

Comment 17 Ryan Hallisey 2020-02-04 11:54:41 UTC
Simone can you provide the needed info?

> The UI is meant to show the default channel:
@Sam, what version of OCP is this in?

Comment 20 Samuel Padgett 2020-02-04 14:16:10 UTC
(In reply to Ryan Hallisey from comment #17)

> @Sam, what version of OCP is this in?

That link was 4.4, but 4.3 is the same:

https://github.com/openshift/console/blob/release-4.3/frontend/packages/operator-lifecycle-manager/src/components/operator-hub/operator-hub-page.tsx#L35-L50

Comment 22 Samuel Padgett 2020-02-05 17:43:52 UTC
I'm not able to reproduce with the provided package manifest. Are you sure this is 4.3 and not 4.2? Looking at the code, I believe we had a bug in 4.2 where it wasn't taking the default:

https://github.com/openshift/console/blob/release-4.2/frontend/public/components/operator-hub/operator-hub-page.tsx#L22-L23

Comment 23 Simone Tiraboschi 2020-02-05 17:49:01 UTC
It's probably 4.2 because we hit that testing the CNV upgrade scenario (CNV 2.1 -> CNV 2.2) and OCP 4.2 -> 4.3 is part of that picture.

Comment 24 Samuel Padgett 2020-02-05 17:55:25 UTC

*** This bug has been marked as a duplicate of bug 1764540 ***

Comment 25 Samuel Padgett 2020-02-05 18:00:13 UTC
This is a duplicate of bug 1764540. I created bug 1798646 to backport the fix to 4.2.z.

Comment 26 Ryan Hallisey 2020-02-05 18:48:00 UTC
thanks Sam.