ClusterSync target user reconcile re-applies password and roles on every reconcile

[ChaoHuang2018]

Hi Percona Server for MongoDB Operator maintainers,

While looking at the ClusterSync target-user reconcile path, I noticed that the existing-user branch appears to run MongoDB updateUser commands on every reconcile, even when the target user already matches the desired state.

The flow is:

• ensureSyncTargetUser calls ensureTargetMongoUser during reconcile:
  target_user.go:64
• ensureTargetMongoUser first calls GetUserInfo:
  target_user.go:123
• if the user exists, it unconditionally calls UpdateUserPass and UpdateUserRoles:
  target_user.go:133-L136
• those helpers send MongoDB updateUser commands:
  mongo.go:717-L723

I saw the design note that the controller re-applies the password and roles on every reconcile to heal drift after CR/Secret recreation. That makes sense for recovery, but the current implementation also means a steady-state reconcile seems to perform two MongoDB admin writes even when nothing changed.

A possible steady-state sequence is:

ClusterSync CR already created
<cr>-pcsm-target-user Secret already exists
target MongoDB user already exists with the Secret password and desired roles

next reconcile:
  GetUserInfo finds the target user
  UpdateUserPass runs updateUser with pwd
  UpdateUserRoles runs updateUser with roles

if either updateUser command has a transient failure:
  ensure sync target user fails
  reconcile surfaces the error in ClusterSync status

Would it be possible to make the steady-state path avoid no-op writes? For example:

• compare the roles returned by GetUserInfo and skip UpdateUserRoles when they already match;
• only re-apply the password when the target-user Secret was newly created, recreated, or otherwise marked as changed;
• or document that repeated password/role reapplication is intentionally required and expected to be safe on every reconcile.

The main concern is avoiding unnecessary MongoDB admin writes and avoiding transient updateUser failures from blocking ClusterSync when the target user already appears converged.

[egegunes]

Hi @ChaoHuang2018, thanks for the report. Since ClusterSync is not released yet, I'll raise this internally and get back to you.

[ChaoHuang2018]

Thanks for taking a look. That makes sense, and I did not realize ClusterSync has not been released yet.

No urgency from my side. I mainly wanted to flag the steady-state behavior before it becomes part of a release: in the existing-user branch, the reconcile path appears to re-run both password and role updates even when the target user already matches the desired state.

The concrete thing to check is whether that repeated reapply is intentionally required for drift recovery, or whether the steady-state path should skip no-op writes when the current user information already matches. Happy to follow up after your internal review.

[gkech]

hey @ChaoHuang2018, indeed we can optimise the flow around updates a little. In general, on the operator we are using an approach with annotation checking to ensure we have updates and apply something or now, so here: #2435 we are following a similar approach.

[ChaoHuang2018]

Thanks, that makes sense. I saw #2435 and the annotation-checking direction looks like the right way to avoid unnecessary no-op updates in this flow. If #2435 is intended to cover the ClusterSync user/password update path here, I am happy for this issue to be closed against that PR. Otherwise I can help check whether the same annotation guard should also be applied at this call site.