You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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.
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 addnamespace
field to theconnectionSecret
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.
The text was updated successfully, but these errors were encountered: