Repository navigation
fix(nats): merge config.merge.accounts with the generated accounts map - #4134
Conversation
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Team Run ID: 📒 Files selected for processing (2)
Included review availability: Your plan provides up to 8 included reviews per hour; 6 remain after this review. 📝 WalkthroughWalkthroughThe NATS Helm template now deep-copies and combines tenant ChangesNATS config.merge rendering
Estimated code review effort: 3 (Moderate) | ~20 minutes Merge Risk: ⚪ Minimal · up to This change prevents duplicate NATS account mappings when generated users and tenant merge configuration are combined, preserving tenant account settings in the rendered HelmRelease. The covered rendering cases indicate no remaining merge-blocking risk. 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
e1800d4 to
2e07995
Compare
scooby87
left a comment
There was a problem hiding this comment.
LGTM (independent cozy-review pass).
The deep-merge is correct: mergeOverwrite $merge lets the generated users list win for the managed account (so a tenant cannot inject a stray user or override generated passwords) while preserving the tenant other keys (jetstream, other accounts, top-level). deepCopy .Values.config.merge before mutating protects .Values. Range order over the passwords map is sorted, so no reconcile churn.
The new test suite is mutation-verified: reverting the template to HEAD~1 turns it RED with the exact bug symptom (mapping key accounts already defined), green after. helm unittest 67/67.
Non-blocking: tenant accounts.<a>.users are silently dropped in favour of the generated ones (correct security posture) — a doc note would help; and the upgrade path re-serialises spec.values once (cosmetic, structurally identical, no pod restart).
With users set the chart emitted accounts.A.users from the generated passwords and then appended .Values.config.merge verbatim. A tenant that also put an accounts block into config.merge, which is the only place to enable JetStream for the generated account, got the key twice in the rendered values and the release failed at post-render. The generated users are now merged into config.merge before it is rendered: the generated list wins for account A, everything else the tenant put under config.merge is kept, and a config.merge without users passes through unchanged. Signed-off-by: Yan Bondarenko <[email protected]>
2e07995 to
334f6ad
Compare
301a7fe
into
cozystack:main
|
Successfully created backport PR for |
What this PR does
Fixes #4084.
With
usersset,templates/nats.yamlrenderedconfig.merge.accounts.A.usersfrom the generated passwords and then appended.Values.config.mergeverbatim. A tenantconfig.mergethat also carriedaccounts, which is the only place to setaccounts.A.jetstreamfor the generated account, produced the key twice in the HelmRelease values, and the install failed at post-render withmapping key "accounts" already defined.The template now builds a single
mergemap: a deep copy of.Values.config.mergewith the generated users merged in underaccounts.A.usersviamergeOverwrite. The generated user list wins for accountA; other keys underaccounts.A, other accounts and top-level keys such asmax_payloadare kept; aconfig.mergewithoutuserspasses through unchanged; and nomergeblock is rendered when neither is set. The values contract does not change.helm unittest: 67/67 in the chart. The newtests/config_merge_test.yamlcovers the six shapes above; against the previous template the same suite fails on the three cases that combineuserswithconfig.merge.accounts.Downstream repositories
Template and tests only: no values, schema, README or defaults change.
Release note
Summary by CodeRabbit
Bug Fixes
Tests