[Enhancement]: Allow customisation of CRD API groups

[neeraj-laad]

Related problem

Strimzi recommends running only a single Cluster Operator per Kubernetes cluster to avoid conflicts that can arise with multiple Strimzi installations, as described in the documentation: https://strimzi.io/docs/operators/latest/deploying#avoiding_deployment_conflicts

While this is manageable on smaller clusters, it becomes much harder on large, multi‑tenant clusters where each namespace is owned by a different line of business or application team. In such environments, coordinating which team installs which CRDs – and which versions – is challenging, and accidental changes by one team can impact others.

Strimzi is a popular project and multiple vendors also ship Strimzi‑based distributions and CRDs (see https://github.com/strimzi/strimzi-kafka-operator/blob/main/ADOPTERS.md#vendors). This further increases the potential for CRD API group conflicts and version incompatibilities between upstream Strimzi and vendor distributions deployed to the same cluster.

Today, the default API group is defined as a Java constant here:

strimzi-kafka-operator/api/src/main/java/io/strimzi/api/kafka/model/common/Constants.java

Line 11 in 42e7817

public static final String RESOURCE_GROUP_NAME = "kafka.strimzi.io";

The CRDs are generated by running the CRD generator as part of the Maven build:

strimzi-kafka-operator/api/pom.xml

Line 172 in 42e7817

<argument>io.strimzi.crdgenerator.CrdGenerator</argument>

Suggested solution

It would be very helpful to have a build‑time configuration option (maven property or similar) to customise the CRD API group. This would allow vendors (and advanced users) to easily change the default Strimzi API group (‎strimzi.io) to a custom group, so that their CRDs are isolated from the upstream Strimzi CRDs and from other vendor distributions on the same cluster.

I appreciate that this is unlikely to be that trivial, but I wanted to start a discussion with the maintainers to understand whether this is something that could be supported and, if so, what constraints or preferred approaches you would have before exploring further.

Alternatives

Continue to manage the potential risks of conflicting resources and versions on a cluster.

Additional context

No response

[scholzj]

While we cannot completely prevent it, it is absolutely not in Strimzi's interest to let everyone create some cheap fake copies of Strimzi. If you use Strimzi, you should use Strimzi. This should be rejected.

[neeraj-laad]

The intent is not to create a copy and take credit for the good work done by the community. Vendors are publicly declaring they are using/providing Strimzi and support the project. The intent is to avoid potential CRD conflicts in the scenarios described above.

[scholzj]

I don't care whether you take credit or not. There is only one Strimzi and one Strimzi API. You should use that. It is in no interest of the Strimzi community that everyone runs some copy of Strimzi with their own kinds because that would only lead to problems, chaos, incompatibility, upgrade issues, etc. It would also completely splinter the whole ecosystem of tools around Strimzi.

[dalelane]

The benefit of this being an existing practice for six years now is that we don't need to speak in hypotheticals and can instead learn from real problems that have occurred, and work together to identify ways to avoid them happening again in future.

Perhaps you could start by describing a few instances of the chaos that you have seen this cause over this time, and examples of what leads you to feel the ecosystem of tools around Strimzi is now splintered?

[im-konge]

From my point of view, this is not something that should be implemented.

I never saw having this kind of possibility across other CNCF projects (or even other open-source projects) that would allow users/vendors to rewrite APIs using some environment variable or something like that.

It can easily become an issue - I can think of scenarios where vendors would do something like this and then ask Strimzi maintainers for helping them out. Or users coming from different products mentioning some "differently named" CRs and CRDs, stating that there is some issue in Strimzi. But where would be the issue exactly? In Strimzi? In your product that rewrites API and other things?

As Jakub mentioned, we cannot prevent anyone in doing these kind of changes. But it's anyway a power or magic of open-source, that if you want to do something like this, you can fork the repository and do the changes - but nobody from the community will help you out. And it will always be some kind of copy. If you want to use Strimzi, use Strimzi.

Also, in case that you want to do this, you should know what you are doing, and not having some possibility to just change the names without knowledge what will be the consequences.

Additionally, what will be next thing when this would be implemented? Configuring labels or annotations names based on environment variable?

This further increases the potential for CRD API group conflicts and version incompatibilities between upstream Strimzi and vendor distributions deployed to the same cluster.

What would be use-case for this? Why would you use vendor distribution with Strimzi on the same cluster? TBH I don't remember about issues like this being reported.

---

Anyway, I'm -1 on this enhancement.

[scholzj]

@dalelane Strimzi is an ecosystem of components built around the Strimzi API. When you decide to change the API by using a different group, you break the API compatibility. It will not work anymore with other tools within the Strimzi project itself (e.g. the Access Operator); with the docs, examples, and blog posts; with other applications built on top of the Strimzi API module; with the wider ecosystem of tools and APIs living outside the Strimzi project itself; and with the other CNCF and open source projects integrating against the Strimzi APIs.

The Strimzi license, of course, allows you to use and modify Strimzi in such a way. So there is nothing wrong with it per-se. And I'm glad that you are happy with your decision to use a different API (although, as far as I know, all other vendors chose not to do this and remained Strimzi compatible). But at the end of the day, you are using a hard fork of Strimzi. And you are NOT a Strimzi compatible product.

I do not think the Strimzi open source project and community has any reason to encourage the creation of such incompatible forks. It is certainly not something that regular Strimzi users should do just to have "different installations" as this issue suggests. Having to change the source code to achieve this seems to be a fitting way. Because it makes it clear that this is a hard fork of Strimzi and it is not something that should be done easily and without proper considerations.

To be honest, I do not think doing the changes to the source code to change the API group are really hard. But even if they are hard, it is actually good. Because vendors who really want to do it should be able to handle it. And it would serve as a good nudge to avoid it for anyone who might do it by mistake.