Cannot create connectionStringSecret in different namespace

[thombohlk]

What did you do to encounter the bug?
Steps to reproduce the behavior:

1. Create a MongoDBCommunity resource in namespace X
2. Add a user with a connectionStringSecret in namespace Y

     users:
       - name: test
         db: test
         passwordSecretRef:
           name: mongo-password
         connectionStringSecretNamespace: some_namespace
         roles:
           - name: dbOwner
             db: test
   

3. Notice the secret being created and deleted every few seconds

What did you expect?
For a stable secret to be present in namespace Y containing the connection string.

What happened instead?
The secret is created and immediately removed again. This is caused by the ownerReference of the secret, which points to the MongoDBCommunity resource in namespace X. This is not allowed, and the secret is therefor garbage collected link.

Operator Information

• Operator Version: 0.13.0
• MongoDB Image used: 8.0.4

Kubernetes Cluster Information

• Distribution: RKE2
• Version: v1.32.5+rke2r1
• Image Registry location: quay

[realtimetodie]

Will this ever be fixed? This makes the MongoDB operator kinda useless, it seems that the operator is not enterprise ready

[realtimetodie]

@nammn @lsierant @mircea-cosbuc @MaciejKaras

[realtimetodie]

So it seems that the operator needs to be deployed in every namespace once and the connectionStringSecretNamespace property is useless. Is this by design or is this a bug? Because we have hundreds of namespaces this is a show stopper for us.

[vinilage]

Hi @realtimetodie, thanks for raising this.

This is actually a feature request for our Community Operator, as it currently doesn’t support connectionStringSecret in a different namespace. I’ve opened an internal feature request for it, but please note it may take some time to release due to our current priorities.

If you have complex deployments, I’d strongly recommend using our Enterprise Operator, which is designed for enterprise use cases and provides dedicated support with an SLA, if needed.

Again, thanks for helping us improving our community offering.