OLM picks an operator dependency randomly for operators handling same resources kind provided by the same CatalogSource

[ppatierno]

Bug Report

A Strimzi user reported this issue on our project strimzi/strimzi-kafka-operator#2265 and it seems that the OLM selects which operator dependency to use quite randomly.
The Strimzi and the AMQ Streams operators handle the same resources kind in this specific use case, but which dependency is used isn't deterministic.

What did you do?

Specifying requirements for an operator in this way.

required:
    - description: Represents a Kafka cluster
      displayName: Kafka
      kind: Kafka
      name: kafkas.kafka.strimzi.io
      version: v1beta1
    - description: Represents a topic inside a Kafka cluster
      displayName: Kafka Topic
      kind: KafkaTopic
      name: kafkatopics.kafka.strimzi.io
      version: v1beta1

What did you expect to see?
The OLM should always pick the same operator dependency.

What did you see instead? Under which circumstances?
The OLM should always pick an operator dependency randomly.

Environment

Strimzi version: 0.14.0 (AMQ Streams 1.3.0)
Installation method: OperatorHub.io
Kubernetes cluster: OpenShift 4.2
Infrastructure: CRC

[radtriste]

Hello,

We are having conflicts on OLM for our operator.
We have a problem for DataGrid and Infinispan operators (Red Hat & Community catalogs):
infinispan/infinispan-operator#226

This is also problematic with AMQ Streams & Strimzi (Red Hat & Community catalogs).

[dmesser]

@radtriste The behaviour is deterministic: if dependencies are required and multiple Operators exist to fulfil them, the following is the order of preference:

1. Operators from the same catalog
2. Operators from other catalogs in the same namespace
3. Operators from any other catalogs in other namespaces

If you want to force your Operator to be using a particular dependent Operator, you would ship them in the same catalog. There was a bug in an older OLM version, that did not implement this behaviour correctly and it seemed non-deterministic which Operator was chosen.

[radtriste]

@dmesser Thx for the answer. So it should be corrected by now.
In which version was it corrected ?

[dmesser]

@radtriste https://github.com/operator-framework/operator-lifecycle-manager/tree/0.13.0

[radtriste]

Testing on Openshift 4.2.9 and this seems indeed corrected. I cannot reproduce the problem.
@ppatierno We are ok with that. You may close this one.

[ppatierno]

@radtriste @dmesser thanks you guys!