+++ 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
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.