+++ 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):
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
Jaeger is installed in the community version from the community catalog
Jaeger is installed in the supported version, from the redhat-operators catalog which is the same Operator that OpenShift Service Mesh was installed from.
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.