robintra/perf-sentinel chart-v0.20.1

perf-sentinel chart v0.20.1

on GitHub

What's new in chart-v0.20.1

No template changes, no values.yaml key added or removed, and the rendered config.toml is untouched, so checksum/config stays where it was and pods roll on the image alone, the way they did on chart-v0.19.0. appVersion moves to 0.20.1, and that is the whole of this release: the daemon it ships no longer refuses to start on a file this chart's own defaults had weakened.

The configuration this chart recommends was the one that broke

chart-v0.20.0 told you to put [daemon.incidents] archive_path on the PVC, for a good reason, the record living in memory otherwise. The default podSecurityContext in this chart carries fsGroup: 65534, and mounting a volume under an fsGroup adds g+rw to the files already on it. So the archive the daemon had created at 0600 came back at 0660, and a 0.20.0 daemon refused that mode and exited before it ever reached a write.

Every restart met the same file, so the pod stayed in CrashLoopBackOff until someone ran a chmod from outside the product, and the daemon that had captured incidents was the one that would not come back. Following the recommendation was enough to reach it, on the first restart after the first incident.

The daemon in this release chmods an archive it owns back to 0600 and still refuses one owned by another user. Nothing to set and nothing to change in values.yaml, the upgrade is the fix.

Files on the PVC that were readable by anyone

[daemon.archive] path and the files it rotates into were created at the container umask, so they landed at 0644 next to an ack store that has refused a weak mode since it existed. They hold the whole window Report, every finding, endpoint and normalized SQL shape. They are created 0600 now, on creation only: a file already on the volume keeps the mode it has, so run chmod 600 on it yourself if you want the older ones in line.

Upgrade impact

• A daemon in CrashLoopBackOff on incident archive has mode 660 comes back on this upgrade, with no manual chmod first. If you already worked around it by widening the mode, the daemon narrows the file back to 0600 on startup.
• Pods roll on the image alone. checksum/config does not move, since no rendered configuration changes, and no default value changes with it.
• New window archives on the PVC are created 0600 where they were 0644. Files already there keep their mode, so a sidecar or a job reading them under another account carries on until you change it.
• No values.yaml key is added or removed, no template changes, and the shipped PrometheusRule is untouched.

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

Upgrade an existing release:

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

Read docs/HELM-DEPLOYMENT.md for the ServiceMonitor section, sizing and Ingress postures. The daemon image moves on this release, so the v0.20.1 binary notes describe what changes inside the pod.

If you are upgrading from chart-v0.18.0 or earlier, read the chart-v0.19.0 notes first: that release adds a grouping label to five metrics and is breaking for an unaggregated alert on any of them. From chart-v0.16.0 or earlier, read the chart-v0.17.0 notes as well, which drop the shipped PrometheusRule from seven alerts to five.

Full Changelog: chart-v0.20.0...chart-v0.20.1