Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Using a single secret to connect to non operator managed RabbitMQ cluster #851

Closed
AntonAleksandrov13 opened this issue Jul 11, 2024 · 2 comments

Comments

@AntonAleksandrov13
Copy link

AntonAleksandrov13 commented Jul 11, 2024

Is your feature request related to a problem? Please describe.
We are running a multi-tenant platform where each tenant requires to have numerous RabbitMQ objects created. Each tenant is has its own namespace. As we use non operator managed RabbitMQ cluster, we have to create a secret object with connection information in each namespace. When a tenant needs to be "destroyed", we would usually delete a namespace object.
Once we have started using the topology operator, we had to rewrite deletion process to delete RMQ objects first. Because if we simply delete a namespace, the connection secret there will be deleted first as it does not require finalizers.
That worked fine until the platform grew significantly where multiple object reconciliation are happening at the same time. That meant there were no guarantee when resources will be deleted. This has resulted in over 150 terminating namespaces with 10-20 objects that operator attempts to reconcile. This adds to the existing load on the operator which affects tenant creation.

Describe the solution you'd like
I propose not to restrict rabbitmqClusterReference.connectionSecret to the namespace where RMQ objects are placed. For example, it's possible to add namespace field to the connectionSecret object. Considering that the operator can already read secrets across multiple namespaces this seems like an okay solution.

Describe alternatives you've considered
From our side we have added checks specifically for RabbitMQ objects during destroy operation. But as I have described above we cannot fully rely on checks if reconciliation time grows.

Alternatively, using RMQ cluster operator can help with this because then we can use reference to RMQ cluster, but this seems like a lenghty migration to a new cluster just to have convenience.

Additional context
I am happy to discuss this proposal and I am willing to contribute.

@Zerpet
Copy link
Contributor

Zerpet commented Jul 11, 2024

This should be possible since #700. Documenting this enhancement fell through the cracks, unfortunately. We will greatly appreciate if you make a contribution to the docs for this feature: https://github.com/rabbitmq/rabbitmq-website/blob/main/kubernetes/operator/using-topology-operator.md

In summary, the namespace in rabbitmqClusterReference.Namespace is considered for accessing Secrets cross-namespace, as long as the Secret has the annotation rabbitmq.com/topology-allowed-namespaces, following the rules documented here.

@AntonAleksandrov13
Copy link
Author

I will review the functionality you have mentioned and contribute to the docs. Thanks a lot!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants