Mikhail
My feedback
4 results found
-
3 votesMikhail
supported this idea
·
-
5 votes
An error occurred while saving the comment Mikhail
supported this idea
·
-
5 votes
This is something we're considering for the future.
But the biggest problem we need to solve is that it's incredibly easy to create/delete/update databases within a deployment via many other interfaces. But if this happens, the Operator's source of truth (the custom resources) won't contain the changes, and the Operator would overwrite the changes using it's source of truth.
Mikhail
supported this idea
·
-
5 votes
We're planning an investigation into this in Q2 (May-July for us). It's something more than one customer has asked for and allowing an Atlas ID to be used rather than a reference for another K8s resource feels like a reasonable approach.
No commitments for now till we've investigated in a little more detail.
Mikhail
supported this idea
·
Yes, I confirm that issue in the Atlas k8s operator v2.3.1. More context:
If `AtlasProject` has an annotation `mongodb.com/atlas-reconciliation-policy: "skip"`, then this `AtlasProject` has an empty status field, which doesn't allow to create `AtlasDatabaseUser` referring this project. The error is:
{"level":"INFO","time":"2024-07-12T09:57:18.639Z","msg":"Status update","atlasdatabaseuser":"my-namespace/my-dbuser","lastCondition":{"type":"DatabaseUserReady","status":"False","lastTransitionTime":null,"reason":"DatabaseUserNotCreatedInAtlas","message":"groupID is invalid because must be set"}}