[settings-naming] rename resourceMonitor -> resourceMonitor.enabled (D2)

[aptracebloc]

What

RFC-0076 S14. Renames the Helm value resourceMonitor: <bool> to resourceMonitor.enabled: <bool>, following the D2 convention that component booleans are <component>.enabled.

Closes #1009
Part of tracebloc/backend#3391

The breaking-change hotspot, and how it's avoided

This is a bool -> object change. An existing customer values.yaml, a persisted values file, or a bare --set resourceMonitor=true still supplies a scalar. Two crashes are possible during the alias window, in opposite directions:

• a template that reads .Values.resourceMonitor.enabled blindly fails "can't evaluate field enabled in interface {}" on the legacy scalar; and
• the old ne .Values.resourceMonitor false gate crashes "incompatible types for comparison: map and bool" on the new object (this actually bit NOTES.txt, which the earlier grep missed).

So every reader now routes through one new helper, tracebloc.resourceMonitorEnabled, which resolves the effective flag from whichever shape is present:

input	resolves to
resourceMonitor: true / false (legacy scalar)	the scalar itself
resourceMonitor.enabled: true / false (new object)	.enabled
resourceMonitor: {} (object, .enabled absent)	enabled (default)
absent / null (--reuse-values from a pre-key chart)	enabled (historical default)

It picks the shape with kindIs and prefers the new .enabled form. Effective behaviour is unchanged — resourceMonitor.enabled=true does exactly what resourceMonitor=true did. Emits "true"/"", so callers use it in and/or and not (include ...) for the disabled case, the same idiom as tracebloc.nodeAgentsInUse.

Values-file merges were the subtle case: helm's -f coalescing differs from --set, but the user's scalar still wins over the new map default (verified an operator's resourceMonitor: false from a values file still disables the DaemonSet). The only artifact is a benign cannot overwrite table with non table coalesce info log when a legacy scalar meets the map default; lint stays green.

Schema

values.schema.json now accepts both a boolean and an object, so the legacy scalar is never rejected. The object form closes its keys (additionalProperties: false) so a mistyped enabled (e.g. enable:) is refused loudly at chart load instead of silently dig-defaulting back to true and turning the monitor back on — same reasoning this schema already applies to channelTags.

Readers migrated (8)

resource-monitor-daemonset.yaml, resource-monitor-rbac.yaml, resource-monitor-scc.yaml, secrets.yaml (cross-namespace mirror), rbac.yaml (node-agents Role), jobs-manager-deployment.yaml (NODE_AGENTS_NAMESPACE env), NOTES.txt, and the two _helpers.tpl predicates resourceMonitorRefreshPinned / nodeAgentsInUse. Out of scope and untouched: images.resourceMonitor.digest (a separate image-config map).

Verification

• helm lint --strict green across all four platform values files.
• helm template renders correctly for legacy scalar (true/false), new object (enabled: true/false), unset, null, and {}; the mistyped-key case is refused by the schema.
• helm unittest ./client: 703 pass. Added cases to tests/resource_monitor_test.yaml for legacy scalar, new object, unset default, null, {}, both disabled shapes, and the mistyped-key schema rejection.
• Chart.yaml version + appVersion bumped 1.9.107 -> 1.9.108 (required by chart-version-guard); guard verified passing locally.

— drafted with Claude Code

🤖 Generated with Claude Code

---

Note

Medium Risk
Bool-to-object Helm value changes can mis-gate the resource-monitor DaemonSet on upgrade if alias logic is wrong; behavior is intended to stay identical when legacy scalars or --set resourceMonitor=true|false are used.

Overview
Renames the Helm value resourceMonitor: <bool> to resourceMonitor.enabled: <bool> (RFC-0076 D2) and bumps the chart to 1.9.116.

To avoid breaking upgrades, a new tracebloc.resourceMonitorEnabled helper is the single gate: it accepts the legacy scalar, the new object (defaulting missing .enabled to on), and unset/null the same way as before. DaemonSet/RBAC/SCC/secrets, jobs-manager NODE_AGENTS_NAMESPACE, post-install NOTES, and resourceMonitorRefreshPinned / nodeAgentsInUse now call that helper instead of comparing .Values.resourceMonitor directly.

values.yaml defaults to the object form; values.schema.json allows boolean or object (closed keys so typos like enable: fail at load). Helm unittest cases cover both value shapes and disabled paths.

^{Reviewed by Cursor Bugbot for commit dbbc917. Bugbot is set up for automated code reviews on this repo. Configure here.}

[saqlainsyed007]

Approve. Clean D2 rename: resourceMonitor (scalar) → resourceMonitor.enabled (object) routed through a single tracebloc.resourceMonitorEnabled helper that coalesces both shapes for the alias window. All eight gates converted, no dangling old-name reads, schema accepts the legacy scalar and rejects mistyped sub-keys, and the new tests cover scalar/object/null/{}/mistyped-key. Behavior-preserving, green CI, no conflicts.

[saadqbal]

The bool→object shim is the right shape here — single helper, kindIs on both directions, schema accepting either type with the object's keys closed. I ran it locally rather than take the description's word for it: legacy scalar, new object, unset, null and {} all render as documented, the mistyped enable: key is refused at load, and a values-file resourceMonitor: false still wins over the new map default (only the collector DaemonSet survives). 703/703 unittests, lint green on all four platform files. Catching that NOTES.txt was crashing in the other direction — comparing a map to a bool — was the good find.

Two doc leftovers, neither blocking. The daemonset's preflight fail now tells operators resourceMonitor.enabled: false and points them at SECURITY.md — but docs/SECURITY.md:103 still says resourceMonitor: false, so the error message and the doc it cites disagree. And docs/migration-tools/generate.sh:124 still emits the legacy scalar into every values file it generates, which means fresh legacy configs keep getting minted right up to the remove_by date. Worth fixing both while the context is fresh.

Heads up that #1008 also bumps Chart.yaml to 1.9.109 — whoever lands second gets a conflict. No functional overlap though; it never reads resourceMonitor directly.

[aptracebloc]

Rebased onto develop (it had advanced +18 commits while this sat). The only change since your approval is the develop merge + a Chart.yaml re-bump to 1.9.116 (chart-version-guard) — zero logic change; the resourceMonitor templates/values/schema/tests all auto-merged cleanly. Local helm unittest: 743 tests / 41 suites green. Re-requesting your re-approval when you have a sec — thanks!

— drafted with Claude Code

[saqlainsyed007]

Approving. This is a complete, backward-compatible settings rename and the tests cover the full alias-window matrix. CI green, mergeable, no open threads.

Helper is correct. tracebloc.resourceMonitorEnabled coalesces every value shape by kindIs: map → dig "enabled" true $rm (object form, absent .enabled defaults to true), invalid/nil → "true" (the historical absent-is-enabled default), bool scalar → ne $rm false. Both crash directions it exists to prevent are real — a blind ne .Values.resourceMonitor false fails "incompatible types map and bool" on the object, and a blind .Values.resourceMonitor.enabled fails "can't evaluate field enabled in interface {}" on the legacy scalar.

Migration is total. Every gate moved to the helper: the eight ne .Values.resourceMonitor false sites → (include ...), and resourceMonitorRefreshPinned's eq ... false → not (include ...) — the negation is preserved (pinned-when-disabled still holds). Fail message and the SECURITY comment now name resourceMonitor.enabled: false.

Schema tightening is a real gain, not just a rename. resourceMonitor becomes ["boolean","object"] with additionalProperties: false, so a mistyped enable/disabled is refused at chart load instead of silently dig-defaulting back to true and turning the monitor on — a misconfiguration surface the scalar had no sub-key to expose.

Tests hold the bar. The matrix pins legacy scalar true/false, object enabled true/false, unset default, null (--reuse-values from a pre-key chart), {} (object with .enabled absent → default true), and the mistyped-key → failedTemplate. Each renders/refuses through the real template, so a helper regression on any shape reddens. The bare failedTemplate: {} with its note on the 0.5.2 errorPattern limitation (backend#2606) is the right call given the tooling. I'd own this.

[saqlainsyed007]

Re-reviewed at dbbc917. Confirmed every runtime reader of .Values.resourceMonitor now routes through the single tracebloc.resourceMonitorEnabled helper — grep at head shows the only bare .Values.resourceMonitor read left is inside the helper itself (line 155); the other occurrences are comments. The helper correctly coalesces all three shapes (map via dig "enabled" true, invalid/nil → enabled, scalar bool), the schema accepts both forms with additionalProperties: false closing the object, and the unit tests cover legacy scalar / object / null / {} / mistyped-key. CI is fully green (Cursor Bugbot, bugbot / review, Source-of-truth drift, all Template renders, Helm unit tests) with no open threads. LGTM.

Non-blocking nit: the PR body says Chart.yaml bumped 1.9.107 -> 1.9.108, but head actually bumps 1.9.115 -> 1.9.116 — stale description text from re-pushes; the file itself is consistent and version-bump-gate passes.