add proposal for multi namespace topic operator

[KyriosGN0]

This PR aims to introduce a multi namespace topic operator, its based on the proposal for UTO, and uses a different approach as opposed to strimzi/strimzi-kafka-operator#1206

[scholzj]

Thanks for the proposal. I left some comments about things that would not work or would be blockers for me in terms of backwards compatiblity etc.

But I do not think that this is the right direction. While it might create something that somehow works, I think it would be a hacky solution with a bad design and user experience. I think if we want to seriously go into the multi-namespace world, we might need to start from scratch and create a better match/respect for the Kubernetes namespace model.

[scholzj]

Tha naming here as well as below does not work because it is not unique. You need to create a unique naming mechanism (likely cluster name, namespace + some suffix).

[KyriosGN0]

Thanks, I updated the proposal accordingly to ensure uniqueness

[scholzj]

There is already an existing mechanim how to designate to which cluster the topic belongs through the strimzi.io/cluster label. Both from the user as well as from the TO perspective.

I do not understand why don't you use that? You will anyway need to extend it. It also has backwards compatibility implications that you would need to address.

[KyriosGN0]

Good Point, i updated the proposal accordingly

[scholzj]

I don't think the fix works.

• How does the operator know it is in single namespace or multi namespace mode?
• How does it know if there are more clusters (more TOs watching the same namespace) or not?

So I'm not sure this works or creates backwards compatile solution.

[scholzj]

That does not work because once you remove the namespace, it is beyond the operator's reach. So it cannot remove the finalizers.

[KyriosGN0]

I think you mean when someone else deletes the namespaces, and not when someone removes a namespace from the watchedNamespaces list, in the first case you are right and manual intervention is required, but if i remove a namespace from the operator's config i can perform action before i remove RBAC, i updated the proposal to make sure this is clear

[scholzj]

Sorry, maybe my comment was too confusing.

• Cluster Operator does not touch any topics. It should not remove any finalizers from them. (not 100% sure the CO is typo here or intention)
• Topic Operator would never know that some namespace was removed as it is removed through restart. So it starts with the new namespace configuration and has no idea a namespace was removed.
• And even if it knew about it, it would not have the RBAC rights to do anything with the topics because the RBAC rights are managed independently through CO, and there is no synchronization point.
• Plus we in general do not delete the user-facing custom resources.

I do not think you can really fix it to be honest. All what can be done here is that this is user's responsibility to either delete the topics first or manually later.

[scholzj]

How does this handle compatibility witht he existing watchNamespace field?

[KyriosGN0]

Updated the Proposal, i went with a route of depreacting this field in favor of the plural one

[scholzj]

Deprecation is fine. But we are not abandoning fields from one day to another. We do things in backwards compatible way.

[scholzj]

If you don't manage it, you should not touch it. That will just cause tight reconciliation look as the two operators fight over the updates.

[KyriosGN0]

Addressed

[KyriosGN0]

Thanks @scholzj, I Have addressed your comments

1. Updated the RBAC names to be unique
2. added that the new plural watchNamespaces is deprecating watchNamespace
3. clarified that removing a namespace from watchNamespaces is different from deleting a namespace