Hello!
We're using Strimzi Operator as a dependency for our own operator and sometimes OLM installs AMQ Streams instead of Strimzi. This is happening because both define the same kind, name and version:
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
Is it possible to have different kind for AMQ Streams ? That way we can differentiate from the upstream/downstream projects.
We add it as a dependency in the operator manifest and there is no way to set the exact operator we want.
Here's more info about OLM dependency management: https://github.com/operator-framework/operator-lifecycle-manager#dependency-resolution
This goes in the same way as https://github.com/strimzi/strimzi-kafka-operator/issues/1247
Expected behavior
I would like to have Strimzi installed and not AMQ Streams.
Environment:
@radtriste I had an offline chat with some people working on OLM and it seems the expected behavior right now but they asked me to open an issue for fixing it.
It seems that the idea is the following:
OLM will prioritize resolving dependencies from the same CatalogSource (Example: Your operator was from the community-operators CatalogSource , and has a dependency on an API defined in both certified-operators and community-operator CatalogSources, the dependency will come from community-operators.
Feel free to add any comments on the issue I just opened.
Anyway it's really not a Strimzi bug, I am sorry.
@ppatierno Seems fine and logical. I will follow-up on the opened issue.
So I guess we can close this issue? If you want, I can open one downstream for AMQ Streams, since the renaming would need to happen there. But I'm a bit sceptical about when we would get to it, since it would require some build changes etc.
I close it. I will follow-up on the OLM issue opened.
Most helpful comment
@radtriste I had an offline chat with some people working on OLM and it seems the expected behavior right now but they asked me to open an issue for fixing it.
It seems that the idea is the following:
OLM will prioritize resolving dependencies from the same
CatalogSource(Example: Your operator was from thecommunity-operatorsCatalogSource , and has a dependency on an API defined in bothcertified-operatorsandcommunity-operatorCatalogSources, the dependency will come fromcommunity-operators.Feel free to add any comments on the issue I just opened.
Anyway it's really not a Strimzi bug, I am sorry.