robintra/perf-sentinel chart-v0.14.0

perf-sentinel chart v0.14.0

on GitHub

What's new in chart-v0.14.0

An appVersion move from 0.13.1 to 0.14.0, and nothing else. No template changes, values.yaml untouched, so a values file renders the same objects as 0.13.1 apart from the image tag, the chart version labels and the checksum they feed.

Behavior

• A daemon deployed on OVHcloud, Scaleway or 3DS OUTSCALE now scores its carbon instead of reporting zero. Those regions fell into the synthetic unknown bucket, which contributes no operational CO2, so perf_sentinel_carbon_gco2 sat pinned at 0 on three European sovereign clouds and any Grafana panel or alert built on it read a wrong figure rather than a missing one. 42 region keys join the table. Set [green] default_region under daemon.config to a key the table now knows, gra11, fr-par-1 or the like, since a region the daemon cannot name still falls back to the generic prior.
• An OUTSCALE deployment must use the outscale- prefixed keys. OUTSCALE reuses AWS region identifiers for different places: its eu-west-2 is Paris where the AWS one is London, 41.5 against 217.4 gCO2/kWh on the same string. [green] default_region = "outscale-eu-west-2" scores Paris, the unprefixed value stays the AWS London region it has always been. No existing values file changes meaning.
• perf_sentinel_energy_kwh moves on OVHcloud and Scaleway, downward. PUE is applied per provider, 1.24 for OVHcloud and 1.375 for Scaleway, where an unrecognised region carried the generic 1.5. That is roughly 17% and 8% less attributed energy on identical traffic. OUTSCALE publishes no PUE and rents rather than operates its datacenters, so its rows keep the generic prior and its energy figure does not move.
• daemon.config accepts [green.cloud] provider = "scaleway". 65 Scaleway instance types gain an embedded power profile, so a daemon can attribute idle and peak wattage per instance type as it already could on the three hyperscalers. OVHcloud and OUTSCALE are still refused there, since neither documents the CPU an offer runs on. Those nodes stay covered by the Alumet or Scaphandre backends.
• The Prometheus surface is unchanged. The carbon and energy gauges are scalar by design, with no per-region or per-service label, so 42 new regions add no series and no label value and /metrics keeps its cardinality. What changes is the value on those gauges, not the shape of the exposition.
• query inspect against the in-cluster daemon gains --sort, and its TUI gains two keys. s sorts findings inside the selected trace and f cycles the severity filter, and the Detail panel now carries the per-span timing, the n+1 classification, the observation window and the confidence. query monitor is deliberately untouched.
• The upgrade rolls the pods. The image tag falls back to .Chart.AppVersion when image.tag is empty, which is the default, so the pod spec moves from 0.13.1 to 0.14.0. The checksum/config annotation also changes, since the ConfigMap carries the chart version in its labels. Pinning image.tag explicitly keeps the old image and skips the rollout.
• Nothing else in the daemon changes. The rest of 0.14.0 reworks the HTML dashboard, which perf-sentinel report produces and this chart does not run. Routes and wire formats are unchanged: /api/findings, /api/correlations, /api/export/report, /metrics and the OTLP listeners answer in exactly the same shapes, and the archived per-window JSON keeps its shape. Findings, thresholds and signatures are untouched, so no acknowledgment and no baseline moves on this upgrade.

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.14.0

Upgrade an existing release:

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

Verify that the rollout picked up the new image:

kubectl get pod -l app.kubernetes.io/name=perf-sentinel \
  -o jsonpath='{.items[*].spec.containers[*].image}'

Read docs/HELM-DEPLOYMENT.md for the sizing guidance, the Ingress postures, the NetworkPolicy peer an ingress controller needs, and the acknowledgments ConfigMap mount. The v0.14.0 binary notes carry the full account of the changes above, including which region keys were added and where their grid intensities come from.

If you are upgrading from chart-v0.12.0 or earlier, read the chart-v0.13.0 notes first: that release makes a mounted acknowledgments ConfigMap reload without a pod restart, and it stops a ConfigMap projection from blocking startup. Mount that ConfigMap as a directory, a subPath mount defeats the reload.

Full Changelog: chart-v0.13.1...chart-v0.14.0