[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
Touches many install gates (DaemonSet, RBAC, secrets, jobs-manager env) for a widely enabled component; mitigated by a centralized helper and broad unittest coverage, but wrong coalescing during upgrades could still mis-toggle the monitor.

Overview
RFC-0076 (D2): The Helm value moves from scalar resourceMonitor: <bool> to resourceMonitor.enabled: <bool>, with chart 1.9.109 and defaults/schema updated accordingly.

Because that is a bool→object rename, upgrades can still supply a legacy scalar (values.yaml, --set resourceMonitor=true, --reuse-values). The PR adds tracebloc.resourceMonitorEnabled as the single gate: it uses kindIs to accept legacy bool, new { enabled: … } (defaulting missing enabled to on), and absent/null as historically enabled—avoiding template failures from comparing map vs bool or reading .enabled on a scalar.

All DaemonSet-related rendering (DaemonSet, RBAC, SCC, cross-namespace secret mirror, node-agents Role, jobs-manager NODE_AGENTS_NAMESPACE, NOTES, image-refresh / nodeAgentsInUse helpers) now calls that helper instead of ne .Values.resourceMonitor false. Schema allows boolean or object (object keys closed so typos like enable: fail at load). helm-unittest cases cover legacy/new/disabled shapes and schema rejection.

Effective on/off behavior is unchanged when values are expressed correctly; operators should prefer resourceMonitor.enabled during the alias window (remove_by 2026-12-31).

^{Reviewed by Cursor Bugbot for commit dc8ce41. 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.