robintra/perf-sentinel chart-v0.9.27

perf-sentinel chart v0.9.27

on GitHub

What's new in chart-v0.9.27

The daemon has loaded ordered TOML fragments from .perf-sentinel.d/ since application 0.9.25, and this chart had no way to fill that directory. The ready-to-copy energy backends in examples/ could only reach a cluster pasted by hand into one large config.toml, which is exactly the merge the fragment loader exists to avoid. config.fragments closes that gap, and the six backends now ship as Helm values overlays you stack on the base file. Chart-only release, appVersion stays on 0.9.26, and a values file that carries no config.fragments renders byte for byte as it did under the previous chart, so an upgrade rolls nothing at all.

Added

• config.fragments mounts ordered TOML documents. A map of NN-name.toml keys renders into a second ConfigMap, mounted read-only as a directory at /etc/perf-sentinel/.perf-sentinel.d/. The daemon merges them in ascending NN order, then applies config.toml last as the override. The directory is mounted whole rather than key by key, so adding or removing a fragment reaches a running pod, and the checksum/config annotation now folds in both ConfigMaps, so editing either one rolls the pods. It only folds in the fragments template once that template renders something, which is why an upgrade over a config that did not change stays still.
• One values overlay per energy backend in examples/helm/. alumet, cloud, scaphandre, kepler, redfish and electricity-maps, each the Kubernetes port of the examples/ file of the same number, stackable on the base values with a second -f. Endpoints resolve through in-cluster DNS rather than localhost, credentials move to a Secret read via extraEnvFrom, and each overlay names the Kubernetes prerequisite it assumes. Every field of the source .toml is mirrored, and the exemptions are listed in examples/helm/README.md rather than left to be rediscovered.
• The three per-node scrapers now state their reach. Alumet, Kepler and Scaphandre run as DaemonSets, and a ClusterIP in front of a DaemonSet load-balances each scrape to one arbitrary pod, which answers for its own node only. On a single-node cluster that is the whole cluster. On a multi-node one the attributed energy hops between nodes and under-reports without ever failing, so the overlays now spell that out and point at a Prometheus federation endpoint as the cluster-wide alternative, with the caveat that keeping the metric name and label intact through federation depends on your own relabeling.

Changed

• Two render-time guards, because the daemon validates at startup and the image has no shell. A boot failure in a FROM scratch image leaves nothing to read the error in, so both rules move to helm template. Fragment names must be NN-lowercase-name.toml with a two-digit NN, a [a-z0-9-] slug and no shared priority, which is exactly what the loader accepts. And listen_port_* and turning [green] off are rejected inside a fragment, as are [daemon.ack] and [daemon.archive] when persistence has the chart writing them itself. Those are the keys the chart cross-checks against service.ports.*, the probes and the PVC while reading config.toml alone, so a fragment redefining one would pass a green check and still produce a pod listening where nothing routes, or a TOML with a table opened twice. Without persistence, or with manageDaemonPaths=false, you own the ack and archive paths and a fragment carrying them renders fine.
• The reserved-key check folds TOML spellings into one before matching. A spaced header [ green ], a quoted "listen_port_http" and an inline green = { enabled = false } are caught like the plain spelling, while a reserved key merely named in a comment is not. Twenty-two scenarios in scripts/test/chart-render-guards-test.sh pin the whole surface.
• values-perf-sentinel.yaml regains n_plus_one_messaging_warning_max. The bundled config.toml has carried that threshold since 0.9.23 and the example had drifted from it. The overlay file itself stays backend-free, so the base values install unchanged and a backend is a deliberate second -f.

Fixed

• scripts/test/examples-helm-load-test.sh loads what the render produced. It projects both ConfigMaps the way kubelet does, real files under a timestamped directory, a ..data symlink and one relative symlink per key, then hands the result to a real binary. helm template proving that a values file renders says nothing about whether the daemon accepts what came out, and a fragment that parses but does not validate renders fine and CrashLoopBackOffs. The script also plants an unparseable fragment in that directory and requires the binary to reject it by name, because every other assertion it makes is satisfied by config.toml alone and would stay green if the fragments were never read at all.
• Both Helm harnesses now fail on their own faults instead of passing. A test script that mis-invokes helm or loses its fixture used to exit clean, which is the failure mode that makes a suite worth less than no suite. Both scripts assert their own setup, and the parity check fails when a Helm overlay drops a field its source .toml fragment carries.

Behavior

• No change for a values file with no config.fragments. Every workload kind renders identically to 0.9.26, checksum/config included, with no second ConfigMap and no extra volume. An upgrade from the previous chart version is metadata-only and rolls no pod.
• appVersion stays on 0.9.26. No new daemon image, so nothing about detection, scoring, /metrics or the query API moves. The fragment loader this chart now feeds shipped in application 0.9.25 and is already present in the running image.
• The two guards can fail a render that used to pass, but only if you adopt config.fragments. Neither rule can trigger on a values file written for 0.9.26, since that file has no fragments to check.

Install

The chart is published as an OCI artifact on GHCR, install it directly with no helm repo add step:

helm install perf-sentinel oci://ghcr.io/robintra/charts/perf-sentinel --version 0.9.27

Upgrade an existing release:

helm upgrade perf-sentinel oci://ghcr.io/robintra/charts/perf-sentinel --version 0.9.27

Add an energy backend by stacking its overlay on the base values:

helm upgrade perf-sentinel oci://ghcr.io/robintra/charts/perf-sentinel --version 0.9.27 \
  -f examples/helm/values-perf-sentinel.yaml \
  -f examples/helm/values-green-alumet.yaml

Read examples/helm/README.md for what each backend expects from the cluster, and docs/HELM-DEPLOYMENT.md for the fragment rules in full.

Full Changelog: chart-v0.9.26...chart-v0.9.27