Strimzi-kafka-operator: [Bug] Strimzi and AMQ Streams operators define the same kind, name and version

Created on 2 Dec 2019  路  4Comments  路  Source: strimzi/strimzi-kafka-operator

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:

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

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

All 4 comments

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

Was this page helpful?
0 / 5 - 0 ratings