Namespace collision with rabbitmq/cluster-operator

[Kamaradeivanov]

Describe the bug

Hello, first thing, thanks for the great job you have done with the both rabbitmq operator.

I'm currently using argocd to deploy rabbitmq in a gitops way. Recently i want to add Messaging Topology Kubernetes Operator to create vhost, policy and user with CRD.

To do that I try to used kustomize to easily deploy rabbitmq/cluster-operator and rabbitmq/messaging-topology-operator but i'am currently facing a collision because the each operator deployment yaml start with :

apiVersion: v1
kind: Namespace
metadata:
  labels:
    app.kubernetes.io/component: rabbitmq-operator
    app.kubernetes.io/name: rabbitmq-system
    app.kubernetes.io/part-of: rabbitmq
  name: rabbitmq-system

To Reproduce

To do that i' have the following kustomize file

apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization

resources:
  - https://github.com/rabbitmq/cluster-operator/releases/download/v2.0.0/cluster-operator.yml
  - https://github.com/rabbitmq/messaging-topology-operator/releases/download/v1.10.0/messaging-topology-operator.yaml

Then I run

kustomize build .

And I got the following error

Error: accumulating resources: accumulation err='merging resources from 'https://github.com/rabbitmq/messaging-topology-operator/releases/download/v1.10.0/messaging-topology-operator.yaml': may not add resource with an already registered id: ~G_v1_Namespace|~X|rabbitmq-system': evalsymlink failure on '/tmp/kustomize-377141229/releases/download/v1.10.0/messaging-topology-operator.yaml' : lstat /tmp/kustomize-377141229/releases: no such file or directory

Expected behavior

In your (documentation)[https://github.com/rabbitmq/messaging-topology-operator/#quickstart] you says that :

Before deploying Messaging Topology Operator, you need to have:

1. A Running k8s cluster
2. RabbitMQ [Cluster Operator](https://github.com/rabbitmq/cluster-operator) installed in the k8s cluster
3. A [RabbitMQ cluster](https://github.com/rabbitmq/cluster-operator/tree/main/docs/examples) deployed using the Cluster Operator

If the RabbitMQ Cluster Operator must be installed why do you also create the nemaspace in the Messaging Topology Kubernetes Operator ?

Version and environment information

• kustomize: v4.4.0
• kubectl: v1.24.7
• RabbitMQ Cluster Operator: v2.0.0
• RabbitMQ Messaging Topology Kubernetes Operator: v1.10.0

[DanielePalaia]

Hi @Kamaradeivanov since version 1.4.0 the messaging topology operator can be deployed without requiring the cluster-operator ( https://www.rabbitmq.com/kubernetes/operator/using-topology-operator.html#non-operator).

For this reason discussing with the team we decided that it is better not to remove the namespace definition in the messaging-operator definition file.

In the long run there is a plan to merge the messaging operator into the cluster operator but it will not be something recent.

In the meantime is there not any workaround for kustomize that we can implement for example using patchStrategicMerge or some other commands?

For example here it seems like we have the same situation https://stackoverflow.com/questions/72288489/patching-multiple-resources-with-kustomize and was suggested to use components... I'm not a kustomize/argoCD expert but maybe in the community someone have some ideas/workaround we can implement.

In any case I don't really think it can be considered as "bug" of the product.

[mconlonredoak]

1. I want to re-emphasize that your README still states that the cluster operator is required. It needs amendment if the releases assume it's not working in tandem with the cluster operator.

Quickstart
Before deploying Messaging Topology Operator, you need to have:
A Running k8s cluster
RabbitMQ Cluster Operator installed in the k8s cluster
A RabbitMQ cluster deployed using the Cluster Operator

2. It seems like it would be a LOT easier to just add the Namespace resource to the instructions in the non-operator docs (since the additional Secret and Queue resources are needing to be created there), and in the standard release within this repo, leave the namespace out, as the default appears to be to run this operator alongside the cluster operator.

3. If not following point 2, it would be great to provide a funcional workaround for this issue. I've looked into Components and can't really make sense of how that would solve this issue. I'm really curious how the maintainers of this project are deploying this operator alongside the cluster operator without understanding this VERY simple use-case.

Also curious if @Kamaradeivanov ever found a solution to this issue.

[Kamaradeivanov]

Hi @mconlonredoak, sorry but I haven't spent any time on topology operator since I encountered the problem.

But I hope that the kustomise $patch: delete could do the job if you split cluster-operator and messaging-topology-operator into two separate argo applications (or kustomise file).

If you have created a delete patch file called delete-ns.yaml

$patch: delete
apiVersion: v1
kind: Namespace
metadata:
  name: rabbitmq-system

Then apply the patch in your kustomize file.

apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization

resources:
  - https://github.com/rabbitmq/messaging-topology-operator/releases/download/v1.10.0/messaging-topology-operator.yaml

# delete patch
patches:
  - delete-ns.yaml

Not perfect, but I have nothing else to suggest... Or maybe work on a helm chart :P.

[Zerpet]

We expect folks to run kubectl apply to install the operators, or Bitnami's Helm chart. We document so in the installation instructions: https://www.rabbitmq.com/kubernetes/operator/install-topology-operator#installation

This seems like a limitation in kustomize, not an issue in our manifests. IMHO, Kustomize is a terrible tool, with silly limitations like this one, and with an unnecessary complexity to achieve something as simple as merging duplicated resources. An alternative is Carvel's YTT, which works out of the box with our current manifests, and it allows to do more sophisticated YAML manipulation, with some level of complexity, and far more documentation.

Note that you can install both operators using a Bitnami's Helm charts, as described here. IIRC, this Helm chart installs both Operators. The only "catch" with the Helm chart is that it configured the operator to deploy RabbitMQ Bitnami's image, which has some nuances compared to the DockerHub image; however, nothing stops you from setting DockerHub RMQ image in your RabbitmqCluster manifest.

I want to re-emphasize that your README still states that the cluster operator is required. It needs amendment if the releases assume it's not working in tandem with the cluster operator.

I'm hesitant to remove this requirement from the readme, because for most features, we assume that RabbitMQ was deployed using the Cluster Operator. "Non-managed rabbits" is a very specific feature to support star certificates and rabbits off-platform, although it is not limited to just those two use cases.

[mconlonredoak]

Hi @mconlonredoak, sorry but I haven't spent any time on topology operator since I encountered the problem.

But I hope that the kustomise $patch: delete could do the job if you split cluster-operator and messaging-topology-operator into two separate argo applications (or kustomise file).

If you have created a delete patch file called delete-ns.yaml

$patch: delete
apiVersion: v1
kind: Namespace
metadata:
  name: rabbitmq-system

Then apply the patch in your kustomize file.

apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization

resources:
  - https://github.com/rabbitmq/messaging-topology-operator/releases/download/v1.10.0/messaging-topology-operator.yaml

# delete patch
patches:
  - delete-ns.yaml

Not perfect, but I have nothing else to suggest... Or maybe work on a helm chart :P.

Thank you, I just confirmed that this works perfectly. Appreciate it!

[Kamaradeivanov]

Thank you for your feedback