Bug 1763750

Summary: OLM dependency resolution does not prefer the initial catalog
Product: OpenShift Container Platform Reporter: Alexander Greene <agreene>
Component: OLMAssignee: Alexander Greene <agreene>
OLM sub component: OLM QA Contact: Bruno Andrade <bandrade>
Status: CLOSED WONTFIX Docs Contact:
Severity: high    
Priority: unspecified CC: afield, agreene, bandrade, dageoffr, dmesser, jiazha, jmatthew, nstielau, vlaad
Version: 4.1.z   
Target Milestone: ---   
Target Release: 4.1.z   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: 1762769 Environment:
Last Closed: 2020-02-18 14:15:17 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On: 1771638    
Bug Blocks:    

Description Alexander Greene 2019-10-21 14:07:22 UTC
+++ This bug was initially created as a clone of Bug #1762769 +++

Description of problem:

When installing Operator A that express dependencies it is expected that in the case where multiple candidate Operators exist that could fulfil the dependency there is a preference to the catalog where Operator A is installed from.

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

OCP 4.2

How reproducible:

Randomly, but with high probability

Steps to Reproduce:
1. Install OpenShift Service Mesh Operator
2. Observe dependent Operators Jaeger & Kiali getting installed as a dependency
3. Observe the OpenShift Service Mesh getting installed

Actual results:

Jaeger is installed in the community version from the community catalog

Expected results:

Jaeger is installed in the supported version, from the redhat-operators catalog which is the same Operator that OpenShift Service Mesh was installed from.


Additional info:

This issue is already raised upstream as well: https://github.com/operator-framework/operator-lifecycle-manager/issues/1076

--- Additional comment from Daniel Messer on 2019-10-17 12:48:15 UTC ---



--- Additional comment from Alexander Greene on 2019-10-17 13:34:04 UTC ---

Updating targetRelease to 4.3

Comment 18 Dan Geoffroy 2020-02-18 14:15:17 UTC
Closing this as wont fix.  While technically this has been fixed via the attached PR which was merged, it was only fixed for API usage only.  The corresponding bug https://bugzilla.redhat.com/show_bug.cgi?id=1771638 related to backporting the UI changes to automatically subscribe to dependent operators has been closed as wont fix.  In order to avoid customer confusion or send the message that this was resolved while the UI changes were not backported, I feel its best to notify customers to upgrade to 4.2+ to get this functionality.