Bug 1762769 - OLM dependency resolution does not prefer the initial catalog
Summary: OLM dependency resolution does not prefer the initial catalog
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: OpenShift Container Platform
Classification: Red Hat
Component: OLM
Version: 4.2.0
Hardware: x86_64
OS: Linux
unspecified
high
Target Milestone: ---
: 4.3.0
Assignee: Alexander Greene
QA Contact: Jian Zhang
URL:
Whiteboard:
Depends On:
Blocks: 1763749
TreeView+ depends on / blocked
 
Reported: 2019-10-17 12:47 UTC by Daniel Messer
Modified: 2020-01-23 11:08 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
: 1763749 1763750 (view as bug list)
Environment:
Last Closed: 2020-01-23 11:07:51 UTC
Target Upstream Version:


Attachments (Terms of Use)
Screenshot of OpenShift 4.2 OLM UI in the problematic situation (231.20 KB, image/png)
2019-10-17 12:48 UTC, Daniel Messer
no flags Details


Links
System ID Priority Status Summary Last Updated
Github operator-framework operator-lifecycle-manager pull 1080 'None' closed Bug 1762769: Prioritize APIs from same CatSrc 2020-04-02 09:36:26 UTC
Red Hat Product Errata RHBA-2020:0062 None None None 2020-01-23 11:08:19 UTC

Description Daniel Messer 2019-10-17 12:47:22 UTC
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

Comment 1 Daniel Messer 2019-10-17 12:48:15 UTC
Created attachment 1626791 [details]
Screenshot of OpenShift 4.2 OLM UI in the problematic situation

Comment 2 Alexander Greene 2019-10-17 13:34:04 UTC
Updating targetRelease to 4.3

Comment 4 Jian Zhang 2019-10-29 02:34:19 UTC
LGTM, verify it, details in:
Cluster version is 4.3.0-0.nightly-2019-10-28-204422
OLM version:
mac:~ jianzhang$ oc exec catalog-operator-8477764759-662jf -- olm --version
OLM version: 0.12.0
git commit: 3a31383c938c1c6b76babb3d888137a17a3f28cf

1, Install the ServiceMesh operator from the redhat-operators. The dependent operators from the redhat-operators too, lgtm.
mac:~ jianzhang$ oc get sub -n openshift-operators
NAME                                                           PACKAGE               SOURCE             CHANNEL
jaeger-product-stable-redhat-operators-openshift-marketplace   jaeger-product        redhat-operators   stable
kiali-ossm-stable-redhat-operators-openshift-marketplace       kiali-ossm            redhat-operators   stable
servicemeshoperator                                            servicemeshoperator   redhat-operators   1.0

2, Remove that three operators and reinstall them in the default namespace. All of them from the rehat-operators. lgtm.
mac:~ jianzhang$ oc get sub -n default
NAME                                                           PACKAGE               SOURCE             CHANNEL
jaeger-product-stable-redhat-operators-openshift-marketplace   jaeger-product        redhat-operators   stable
kiali-ossm-stable-redhat-operators-openshift-marketplace       kiali-ossm            redhat-operators   stable
servicemeshoperator                                            servicemeshoperator   redhat-operators   1.0
mac:~ jianzhang$ oc get csv -n default
NAME                         DISPLAY                          VERSION   REPLACES                     PHASE
jaeger-operator.v1.13.1      Jaeger Operator                  1.13.1                                 Succeeded
kiali-operator.v1.0.6        Kiali Operator                   1.0.6     kiali-operator.v1.0.5        Succeeded
servicemeshoperator.v1.0.1   Red Hat OpenShift Service Mesh   1.0.1     servicemeshoperator.v1.0.0   Succeeded

3, Install the ServiceMesh from the community, the dependent operrators from the community too, lgtm. 
mac:~ jianzhang$ oc get sub -n test1
NAME                                                      PACKAGE           SOURCE                CHANNEL
jaeger-stable-community-operators-openshift-marketplace   jaeger            community-operators   stable
kiali-stable-community-operators-openshift-marketplace    kiali             community-operators   stable
maistraoperator                                           maistraoperator   community-operators   1.0

mac:~ jianzhang$ oc get csv -n test1
NAME                      DISPLAY                          VERSION   REPLACES                  PHASE
jaeger-operator.v1.14.0   Community Jaeger Operator        1.14.0    jaeger-operator.v1.13.1   Succeeded
kiali-operator.v1.7.0     Kiali Operator                   1.7.0     kiali-operator.v1.6.1     Succeeded
maistraoperator.v1.0.0    Red Hat OpenShift Service Mesh   1.0.0                               Succeeded

Comment 6 errata-xmlrpc 2020-01-23 11:07:51 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-2020:0062


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