Bug 1763750 - OLM dependency resolution does not prefer the initial catalog
Summary: OLM dependency resolution does not prefer the initial catalog
Alias: None
Product: OpenShift Container Platform
Classification: Red Hat
Component: OLM
Version: 4.1.z
Hardware: x86_64
OS: Linux
Target Milestone: ---
: 4.1.z
Assignee: Alexander Greene
QA Contact: Bruno Andrade
Depends On: 1771638
TreeView+ depends on / blocked
Reported: 2019-10-21 14:07 UTC by Alexander Greene
Modified: 2020-02-18 14:15 UTC (History)
9 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of: 1762769
Last Closed: 2020-02-18 14:15:17 UTC
Target Upstream Version:

Attachments (Terms of Use)

System ID Private Priority Status Summary Last Updated
Github operator-framework operator-lifecycle-manager pull 1110 0 'None' closed Bug 1763750: Prioritize APIs from same CatSrc 2020-12-15 01:46:27 UTC

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.

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