Compare commits

...
Author SHA1 Message Date
issue-fix-bot f529698a99 fix: [alert] KubePersistentVolumeFillingUp (paperclip) (#1184)
ci/woodpecker/pr/ci-scripts-test Pipeline was successful
ci/woodpecker/pr/pr-review Pipeline was successful
ci/woodpecker/pr/ci-manifests-test Pipeline was successful
2026-10-07 15:42:50 +00:00
security-bot 60e4ba4d68 chore(image-automation): bump gitea.renner.uno/k.renner/shelly-manager:build.1791385485
ci/woodpecker/cron/issue-fix Pipeline was successful
ci/woodpecker/cron/alert-monitor Pipeline was successful
Updates managed by image-automation-controller.
2026-10-07 15:21:31 +00:00
argus-bot (Paperclip service account) 2f20f2141f Merge pull request 'feat(mqtt): controller main-982231a (push on wake), register sleeping H&Ts 35-38 (REN-1017)' (#1183) from atlas/ren-1017-ht-wake into master 2026-10-07 15:19:42 +00:00
atlas-botandClaude Opus 5.5 099aea3807 feat(mqtt): controller main-982231a (push on wake), register sleeping H&Ts 35-38 (REN-1017)
ci/woodpecker/pr/ci-scripts-test Pipeline was successful
ci/woodpecker/pr/pr-review Pipeline was successful
ci/woodpecker/pr/ci-manifests-test Pipeline was successful
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-07 15:04:18 +00:00
security-bot ee8ae7a8e8 chore(image-automation): bump gitea.renner.uno/k.renner/shelly-manager:build.1791382755
ci/woodpecker/cron/alert-monitor Pipeline was successful
Updates managed by image-automation-controller.
2026-10-07 14:51:31 +00:00
security-bot a760364556 chore(image-automation): bump gitea.renner.uno/k.renner/shelly-manager:build.1791378441
ci/woodpecker/cron/issue-fix Pipeline was successful
ci/woodpecker/cron/alert-monitor Pipeline was successful
Updates managed by image-automation-controller.
2026-10-07 13:21:31 +00:00
security-bot c1ae5dc8d3 chore(image-automation): bump gitea.renner.uno/k.renner/shelly-manager:build.1791374125
ci/woodpecker/cron/issue-fix Pipeline was successful
ci/woodpecker/cron/alert-monitor Pipeline was successful
Updates managed by image-automation-controller.
2026-10-07 12:21:31 +00:00
argus-bot (Paperclip service account) f90dc1847f Merge pull request 'feat(mqtt): HiluX DS8 unit 44 (toilet) on its own account (REN-1017)' (#1182) from atlas/ren-1017-shelly-group5c into master
ci/woodpecker/cron/e2e Pipeline failed
ci/woodpecker/cron/security-scan Pipeline was successful
ci/woodpecker/cron/alert-monitor Pipeline was successful
2026-10-07 11:43:48 +00:00
atlas-botandClaude Opus 5.5 64e7fd1fd2 feat(mqtt): HiluX DS8 unit 44 (toilet) on its own account (REN-1017)
ci/woodpecker/pr/ci-scripts-test Pipeline was successful
ci/woodpecker/pr/pr-review Pipeline was successful
ci/woodpecker/pr/ci-manifests-test Pipeline was successful
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-07 11:37:31 +00:00
argus-bot (Paperclip service account) 52b320db38 Merge pull request 'feat(mqtt): HiluX DS8 units 9 and 31 (bathroom mesh) on own accounts (REN-1017)' (#1181) from atlas/ren-1017-shelly-group5b into master
ci/woodpecker/cron/alert-monitor Pipeline was successful
ci/woodpecker/cron/issue-fix Pipeline was successful
2026-10-07 11:21:43 +00:00
atlas-botandClaude Opus 5.5 18b6fa858c feat(mqtt): HiluX DS8 units 9 and 31 (bathroom mesh) on own accounts (REN-1017)
ci/woodpecker/pr/ci-scripts-test Pipeline was successful
ci/woodpecker/pr/pr-review Pipeline was successful
ci/woodpecker/pr/ci-manifests-test Pipeline was successful
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-07 11:08:10 +00:00
argus-bot (Paperclip service account) 241e10cdc8 Merge pull request 'feat(mqtt): controller main-1d03144 and rotate: false on shelly-2 (REN-1080)' (#1180) from atlas/ren-1080-controller-1d03144-rotate-hold into master
ci/woodpecker/cron/alert-monitor Pipeline was successful
2026-10-07 11:01:27 +00:00
argus-bot (Paperclip service account) 49ece400f3 Merge pull request 'feat(mqtt): HiluX DS8 unit 12 on its own account, one unit first (REN-1017)' (#1179) from atlas/ren-1017-shelly-group5 into master
ci/woodpecker/cron/alert-monitor Pipeline was successful
2026-10-07 10:51:52 +00:00
security-bot 67d2a09e0c chore(image-automation): bump gitea.renner.uno/k.renner/shelly-manager:build.1791369788
Updates managed by image-automation-controller.
2026-10-07 10:51:31 +00:00
atlas-botandClaude Opus 5.5 9b149feaba feat(mqtt): controller main-1d03144 and rotate: false on shelly-2 (REN-1080)
ci/woodpecker/pr/ci-scripts-test Pipeline was successful
ci/woodpecker/pr/pr-review Pipeline was successful
ci/woodpecker/pr/ci-manifests-test Pipeline was successful
main-1d03144 adds the per-account register field `rotate: false`
(mqtt-account-controller PR #6, reviewed in REN-1073). Set it on shelly-2
only. Both changes go in one commit: main-a307693 rejects a register with
the unknown field.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-07 10:31:33 +00:00
atlas-botandClaude Opus 5.5 4526c963d0 feat(mqtt): HiluX DS8 unit 12 on its own account, one unit first (REN-1017)
ci/woodpecker/pr/ci-scripts-test Pipeline was successful
ci/woodpecker/pr/pr-review Pipeline was successful
ci/woodpecker/pr/ci-manifests-test Pipeline was successful
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-07 10:30:27 +00:00
argus-bot (Paperclip service account) 599e9ffe5e Merge pull request 'feat(mqtt): Shelly group 4 (Pro 4PM, Pro 3) on own accounts (REN-1017)' (#1178) from atlas/ren-1017-shelly-group4 into master
ci/woodpecker/cron/issue-fix Pipeline was successful
ci/woodpecker/cron/alert-monitor Pipeline was successful
2026-10-07 10:07:38 +00:00
atlas-botandClaude Opus 5.5 08467a1b7e feat(mqtt): Shelly group 4 (Pro 4PM, Pro 3) on own accounts (REN-1017)
ci/woodpecker/pr/ci-scripts-test Pipeline was successful
ci/woodpecker/pr/pr-review Pipeline was successful
ci/woodpecker/pr/ci-manifests-test Pipeline was successful
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-07 10:01:11 +00:00
security-bot 1a1cdee39e chore(image-automation): bump gitea.renner.uno/k.renner/shelly-manager:build.1791365067
ci/woodpecker/cron/alert-monitor Pipeline was successful
Updates managed by image-automation-controller.
2026-10-07 09:51:31 +00:00
security-bot 9ab53f0621 chore(image-automation): bump lscr.io/linuxserver/lidarr:3.1.0.4875-ls43
ci/woodpecker/cron/issue-fix Pipeline was successful
ci/woodpecker/cron/alert-monitor Pipeline was successful
Updates managed by image-automation-controller.
2026-10-07 07:53:01 +00:00
argus-bot (Paperclip service account) c12aaffad7 Merge pull request 'feat(mqtt): controller main-a307693, retry failed push (REN-1053)' (#1177) from atlas/ren-1053-controller-a307693 into master
ci/woodpecker/cron/issue-fix Pipeline was successful
ci/woodpecker/cron/alert-monitor Pipeline was successful
2026-10-07 07:23:15 +00:00
atlas-botandClaude Opus 5.5 6a17cbc913 feat(mqtt): controller main-a307693, retry failed push (REN-1053)
ci/woodpecker/pr/ci-scripts-test Pipeline was successful
ci/woodpecker/pr/pr-review Pipeline was successful
ci/woodpecker/pr/ci-manifests-test Pipeline was successful
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-07 07:10:49 +00:00
argus-bot (Paperclip service account) bbf767628a Merge pull request 'feat(mqtt): Shelly group 3 (Plus 2PM, Wall Display, Power Strip) on own accounts (REN-1017)' (#1176) from atlas/ren-1017-shelly-group3 into master
ci/woodpecker/cron/alert-monitor Pipeline was successful
2026-10-07 06:42:06 +00:00
atlas-botandClaude Opus 5.5 e1eb919198 feat(mqtt): Shelly group 3 (Plus 2PM, Wall Display, Power Strip) on own accounts (REN-1017)
ci/woodpecker/pr/ci-scripts-test Pipeline was successful
ci/woodpecker/pr/pr-review Pipeline was successful
ci/woodpecker/pr/ci-manifests-test Pipeline was successful
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-07 06:32:54 +00:00
argus-bot (Paperclip service account) dc40b0e084 Merge pull request 'feat(mqtt): Shelly group 2 (Gen1/G3 plugs, 1PM Mini) on own accounts (REN-1017)' (#1175) from atlas/ren-1017-shelly-group2 into master
ci/woodpecker/cron/alert-monitor Pipeline was successful
ci/woodpecker/cron/issue-fix Pipeline was successful
2026-10-07 06:23:08 +00:00
atlas-botandClaude Opus 5.5 5f7cbcfff3 feat(mqtt): Shelly group 2 (Gen1/G3 plugs, 1PM Mini) on own accounts (REN-1017)
ci/woodpecker/pr/ci-scripts-test Pipeline was successful
ci/woodpecker/pr/pr-review Pipeline was successful
ci/woodpecker/pr/ci-manifests-test Pipeline was successful
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-07 06:18:09 +00:00
argus-bot (Paperclip service account) 297d068faf Merge pull request 'feat(mqtt): Shelly group 1 on own MQTT accounts, drop device-list Job (REN-1017)' (#1174) from atlas/ren-1017-shelly-group1 into master
ci/woodpecker/cron/alert-monitor Pipeline was successful
2026-10-07 06:10:13 +00:00
atlas-botandClaude Opus 5.5 84e3843e96 feat(mqtt): Shelly group 1 (5 devices without switched load) on own accounts, drop device-list Job (REN-1017)
ci/woodpecker/pr/ci-scripts-test Pipeline was successful
ci/woodpecker/pr/pr-review Pipeline was successful
ci/woodpecker/pr/ci-manifests-test Pipeline was successful
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-07 06:02:37 +00:00
argus-bot (Paperclip service account) 1cc08a1757 Merge pull request 'chore(mqtt): one-shot Job listing shelly-manager device ids (REN-1017)' (#1173) from atlas/ren-1017-device-list into master
ci/woodpecker/cron/alert-monitor Pipeline was successful
2026-10-07 05:58:57 +00:00
atlas-botandClaude Opus 5.5 55725ea6e8 chore(mqtt): one-shot Job listing shelly-manager device ids (REN-1017)
ci/woodpecker/pr/ci-scripts-test Pipeline was successful
ci/woodpecker/pr/pr-review Pipeline was successful
ci/woodpecker/pr/ci-manifests-test Pipeline was successful
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-07 05:45:08 +00:00
argus-bot (Paperclip service account) 16203265a2 Merge pull request 'feat(mqtt): controller main-4adc9a6, Shelly device 5 on its own account (REN-1017)' (#1172) from atlas/ren-1017-shelly-accounts into master
ci/woodpecker/cron/issue-fix Pipeline was successful
ci/woodpecker/cron/alert-monitor Pipeline was successful
2026-10-07 05:21:29 +00:00
argus-bot (Paperclip service account) f52af8d0da Merge pull request 'network-policies: paperclip pod -> mosquitto :8884 for agents-read (REN-953)' (#1171) from atlas/ren-953-agents-read-paperclip-pod into master
ci/woodpecker/cron/alert-monitor Pipeline was successful
2026-10-07 05:13:00 +00:00
atlas-botandClaude Opus 5.5 f8c83347cc feat(mqtt): controller main-4adc9a6 and Shelly device 5 on its own account (REN-1017)
ci/woodpecker/pr/ci-scripts-test Pipeline was successful
ci/woodpecker/pr/pr-review Pipeline was successful
ci/woodpecker/pr/ci-manifests-test Pipeline was successful
Bump mqtt-account-controller to main-4adc9a6 (shelly-manager#93 client),
give it the shelly-manager API key and URL, and register shelly-5 (Plus i4)
as the first auth: password account. The legacy user shellies stays.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-07 05:06:40 +00:00
atlas-botandClaude Opus 5.5 19996ebdad network-policies: paperclip pod -> mosquitto :8884 for agents-read (REN-953)
ci/woodpecker/pr/ci-scripts-test Pipeline was successful
ci/woodpecker/pr/pr-review Pipeline was successful
ci/woodpecker/pr/ci-manifests-test Pipeline was successful
Agent runs mostly execute in the paperclip pod, not in a sandbox (REN-1001:
TCP timeout to :8884 from paperclip-b65cc7768). Adds the egress rule in
paperclip-egress and the paperclip pod as a source in mosquitto-agent-ingress.
:8884 only; it requires an mqtt-ca client certificate.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-07 05:02:17 +00:00
argus-bot (Paperclip service account) a65387e1b8 Merge pull request 'feat(mqtt): read-only cert account agents-read + agent path :8884 (REN-953)' (#1170) from atlas/ren-953-agents-read into master
ci/woodpecker/cron/issue-fix Pipeline was successful
ci/woodpecker/cron/alert-monitor Pipeline was successful
2026-10-07 03:45:29 +00:00
argus-bot (Paperclip service account) e2e51fd01a Merge pull request 'feat(mqtt): register cert account home-assistant (REN-953)' (#1168) from atlas/ren-953-ha-account into master
ci/woodpecker/cron/alert-monitor Pipeline was successful
ci/woodpecker/cron/issue-fix Pipeline was successful
2026-10-07 03:28:46 +00:00
atlas-botandClaude Opus 5.5 68dd5ad132 feat(mqtt): read-only cert account agents-read for agents (REN-953)
ci/woodpecker/pr/ci-manifests-test Pipeline was successful
ci/woodpecker/pr/ci-scripts-test Pipeline was successful
ci/woodpecker/pr/pr-review Pipeline was successful
Register entry agents-read (read open3e/#, zigbee2mqtt/#, homeassistant/#),
delivered to the paperclip namespace; agent kubectl identities may get that
one Secret; dedicated CNPs open agent sandbox pods -> mosquitto :8884.
Nothing restarts.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-07 03:07:20 +00:00
atlas-botandClaude Opus 5.5 55e2313114 feat(mqtt): register cert account home-assistant (REN-953)
ci/woodpecker/pr/ci-manifests-test Pipeline was successful
ci/woodpecker/pr/ci-scripts-test Pipeline was successful
ci/woodpecker/pr/pr-review Pipeline was successful
Register entry for Home Assistant (ACL readwrite # as the legacy user
homeassistant, different name so it cannot shadow that login) and its Secret
on the controller's revocation list. Nothing restarts.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-07 03:05:15 +00:00
argus-bot (Paperclip service account) faec2f72f2 Merge pull request 'feat(evcc): MQTT login by client certificate (REN-953)' (#1167) from atlas/ren-953-evcc-cert into master
ci/woodpecker/cron/alert-monitor Pipeline was successful
ci/woodpecker/cron/wiki-maintenance Pipeline was successful
2026-10-07 02:58:13 +00:00
argus-bot (Paperclip service account) 8469d99cfd Merge pull request 'chore(deps): pin dependencies' (#1053) from renovate/pin-image-digests into master
ci/woodpecker/cron/issue-fix Pipeline was successful
ci/woodpecker/cron/alert-monitor Pipeline was successful
2026-10-07 02:31:37 +00:00
argus-bot (Paperclip service account) 2913723bb3 Merge pull request 'feat(mqtt): register cert account evcc-client + :8884 path (REN-953)' (#1166) from atlas/ren-953-evcc-account into master
ci/woodpecker/cron/alert-monitor Pipeline was successful
2026-10-07 02:22:29 +00:00
renovate-bot dbccd4cfd7 chore(deps): pin dependencies
ci/woodpecker/pr/ci-scripts-test Pipeline was successful
ci/woodpecker/pr/pr-review Pipeline was successful
ci/woodpecker/pr/ci-manifests-test Pipeline was successful
2026-10-07 02:01:16 +00:00
atlas-botandClaude Opus 5.5 d9f483edd7 feat(evcc): log in to MQTT by client certificate (REN-953)
ci/woodpecker/pr/ci-scripts-test Pipeline was successful
ci/woodpecker/pr/ci-manifests-test Pipeline was successful
ci/woodpecker/pr/pr-review Pipeline was successful
evcc gets broker URL and the PEMs of the register account evcc-client by
env (EVCC_MQTT_*), which override the mqtt block of evcc.yaml in OpenBao.
Reloader restarts evcc when cert-manager renews the certificate.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-07 01:59:23 +00:00
atlas-botandClaude Opus 5.5 f3cf55b0e9 feat(mqtt): register cert account evcc-client, RBAC and :8884 path (REN-953)
ci/woodpecker/pr/ci-scripts-test Pipeline was successful
ci/woodpecker/pr/pr-review Pipeline was successful
ci/woodpecker/pr/ci-manifests-test Pipeline was successful
Register entry evcc-client (deliver evcc, ACL as the legacy user evcc), a
controller Role/RoleBinding in the evcc namespace for its Certificate and
Secret, and :8884 next to :1883 in both evcc<->mosquitto network policies.
Nothing restarts.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-07 01:58:52 +00:00
security-bot 151d037c2a chore(image-automation): bump gitea.renner.uno/k.renner/shelly-manager:build.1791337222
ci/woodpecker/cron/alert-monitor Pipeline was successful
Updates managed by image-automation-controller.
2026-10-07 01:51:30 +00:00
argus-bot (Paperclip service account) f89faa2131 Merge pull request 'feat(zigbee2mqtt): MQTT login by client certificate (REN-953)' (#1165) from atlas/ren-953-z2m-cert into master 2026-10-07 01:47:36 +00:00
argus-bot (Paperclip service account) 9157a153a6 Merge pull request 'feat(mqtt): register cert account zigbee2mqtt-bridge (REN-953)' (#1164) from atlas/ren-953-z2m-account into master
ci/woodpecker/cron/issue-fix Pipeline was successful
ci/woodpecker/cron/alert-monitor Pipeline was successful
2026-10-07 01:28:44 +00:00
atlas-botandClaude Opus 5.5 5be1d0a250 feat(zigbee2mqtt): log in to MQTT by client certificate (REN-953)
ci/woodpecker/pr/ci-scripts-test Pipeline was successful
ci/woodpecker/pr/pr-review Pipeline was successful
ci/woodpecker/pr/ci-manifests-test Pipeline was successful
Z2M, discovery-guard and interview-watch use the certificate of the
register account zigbee2mqtt-bridge on the mTLS listener :8884 instead of
the legacy password. Z2M gets server/ca/cert/key by env because its
configuration.yaml on the PVC is never re-seeded. The init container no
longer renders mqtt_password. The legacy broker user stays until a later
broker roll.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-07 00:50:39 +00:00
atlas-botandClaude Opus 5.5 da3037cb24 feat(mqtt): register cert account zigbee2mqtt-bridge (REN-953)
ci/woodpecker/pr/ci-scripts-test Pipeline was successful
ci/woodpecker/pr/pr-review Pipeline was successful
ci/woodpecker/pr/ci-manifests-test Pipeline was successful
Adds the register entry for Zigbee2MQTT (same ACL as the legacy user
zigbee2mqtt, different name so it cannot shadow the running password login)
and its Secret to the controller's revocation list. Nothing restarts; the
controller picks the register up live and issues mqtt-zigbee2mqtt-bridge-tls
before the Z2M switch lands.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-07 00:48:42 +00:00
argus-bot (Paperclip service account) 6f32c876cf Merge pull request 'feat(mqtt): broker probes use cert account mosquitto-probe (REN-953)' (#1163) from atlas/ren-953-health-probe-cert into master
ci/woodpecker/cron/issue-fix Pipeline was successful
ci/woodpecker/cron/alert-monitor Pipeline was successful
2026-10-07 00:41:05 +00:00
atlas-botandClaude Opus 5.5 968be52833 feat(mqtt): broker probes log in with the cert account mosquitto-probe (REN-953)
ci/woodpecker/pr/ci-scripts-test Pipeline was successful
ci/woodpecker/pr/pr-review Pipeline was successful
ci/woodpecker/pr/ci-manifests-test Pipeline was successful
Adds the register account mosquitto-probe (auth: cert, readwrite health/#),
mounts its certificate into the broker and switches the liveness/readiness
probes to the mTLS listener :8884. Removes the legacy password user health
from passwd, acl, env and the Reloader annotation. The ExternalSecret and
rotator stay until the REN-802 cleanup step.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-07 00:29:18 +00:00
argus-bot (Paperclip service account) 614f0c2f2e Merge pull request 'feat(mqtt): production broker with Dynamic Security next to legacy users (REN-900)' (#1159) from atlas/ren-900-mosquitto-dynsec into master
ci/woodpecker/cron/alert-monitor Pipeline was successful
2026-10-07 00:12:14 +00:00
argus-bot (Paperclip service account) c647b0993e Merge pull request 'network-policies: agent pods -> shelly-manager API via header-stripping :8081 (REN-931, REN-935)' (#1161) from atlas/ren-931-agent-shelly-manager into master
ci/woodpecker/cron/issue-fix Pipeline was successful
ci/woodpecker/cron/alert-monitor Pipeline was successful
2026-10-06 20:00:48 +00:00
security-bot 4e3c37075b chore(image-automation): bump gitea.renner.uno/k.renner/shelly-manager:build.1791314787
ci/woodpecker/cron/alert-monitor Pipeline was successful
Updates managed by image-automation-controller.
2026-10-06 19:51:29 +00:00
atlas-botandClaude Opus 5.5 a3094d56a2 shelly-manager: header-stripping api-proxy on :8081 for agent pods (REN-935)
ci/woodpecker/pr/ci-scripts-test Pipeline was successful
ci/woodpecker/pr/pr-review Pipeline was successful
ci/woodpecker/pr/ci-manifests-test Pipeline was successful
Review 1473: shelly-manager signs in whoever X-authentik-username names when
the peer is in the pod CIDR, so opening :8080 to agent pods let any run sign
in with a forged header and no API key.

Agents now get an nginx sidecar on ${POD_IP}:8081 (Service
shelly-manager-api) that drops X-authentik-username and X-Forwarded-User
before proxying to :8080. Both agent CNPs move from 8080 to 8081, so :8080
stays outpost-only and every agent call needs the API key.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-06 19:50:46 +00:00
atlas-botandClaude Opus 5.5 3e7b4003d3 network-policies: agent pods -> shelly-manager :8080 (REN-931)
ci/woodpecker/pr/ci-scripts-test Pipeline was successful
ci/woodpecker/pr/pr-review Pipeline was successful
ci/woodpecker/pr/ci-manifests-test Pipeline was successful
Egress from paperclip-renner agent pods and a dedicated ingress CNP on
shelly-manager, container port 8080 (socket-LB). All agents: sandbox pods
carry no per-agent label; the API key gates calls.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-06 19:39:15 +00:00
argus-bot (Paperclip service account) 789e013caf Merge pull request 'chore(mqtt): bump mqtt-account-controller to main-b3d5cbb (REN-900)' (#1160) from atlas/ren-900-controller-bump into master
ci/woodpecker/cron/issue-fix Pipeline was successful
ci/woodpecker/cron/alert-monitor Pipeline was successful
2026-10-06 16:09:48 +00:00
atlas-botandClaude Opus 5.5 7bbac34b47 chore(mqtt): bump mqtt-account-controller to main-b3d5cbb (REN-900, REN-902)
ci/woodpecker/pr/ci-scripts-test Pipeline was successful
ci/woodpecker/pr/pr-review Pipeline was successful
ci/woodpecker/pr/ci-manifests-test Pipeline was successful
The REN-902 build denies publishClientReceive by default and grants receive
per read ACL. On its first loop it rewrites the Secret mqtt-dynsec-seed with
that default. The seed must be rewritten before the production broker loads
it (homelab #1159). Still points at the test broker.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-06 16:03:47 +00:00
atlas-botandClaude Opus 5.5 1a00f3c5f7 feat(mqtt): run the production broker with Dynamic Security next to the legacy users (REN-900)
ci/woodpecker/pr/ci-scripts-test Pipeline was successful
ci/woodpecker/pr/pr-review Pipeline was successful
ci/woodpecker/pr/ci-manifests-test Pipeline was successful
REN-802 step 2. The production mosquitto loads the Dynamic Security plugin
and gets a mutual-TLS listener :8884 (server certificate from mqtt-ca).
mqtt-account-controller now manages this broker instead of the test broker.
The nine legacy users keep password_file and acl_file unchanged.

The Dynamic Security default denies publishClientReceive: with acl_file in
the chain, mosquitto 2.0 does not gate SUBSCRIBE, so a receive default of
allow would let every Dynamic Security client read every topic.

The image policy stays on 2.0.x, because 2.1 changes the plugin chain.
The obsolete delete grant on mqtt-test-revoke-tls is dropped.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-06 15:52:19 +00:00
argus-bot (Paperclip service account) b7ead41b70 Merge pull request 'test(mqtt): remove test-revoke from the MQTT register to check revocation (REN-888)' (#1158) from atlas/ren-888-revoke-test-account into master
ci/woodpecker/cron/issue-fix Pipeline was successful
ci/woodpecker/cron/alert-monitor Pipeline was successful
2026-10-06 15:39:04 +00:00
atlas-botandClaude Opus 5.5 a2cbf32888 test(mqtt): remove test-revoke from the MQTT register to check revocation (REN-888)
ci/woodpecker/pr/ci-scripts-test Pipeline was successful
ci/woodpecker/pr/pr-review Pipeline was successful
ci/woodpecker/pr/ci-manifests-test Pipeline was successful
The controller must delete Certificate mqtt-test-revoke, Secret
mqtt-test-revoke-tls and the dynsec client and role acct-test-revoke on its
next loop. Only the register ConfigMap changes; nothing restarts.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-06 15:33:24 +00:00
argus-bot (Paperclip service account) 7c37071660 Merge pull request 'feat(mqtt): deploy mqtt-account-controller with a Dynamic Security test broker (REN-888)' (#1157) from atlas/ren-888-mqtt-account-controller into master
ci/woodpecker/cron/alert-monitor Pipeline was successful
2026-10-06 15:29:02 +00:00
atlas-botandClaude Opus 5.5 20364c445e feat(mqtt): deploy mqtt-account-controller with a Dynamic Security test broker (REN-888)
ci/woodpecker/pr/ci-scripts-test Pipeline was successful
ci/woodpecker/pr/pr-review Pipeline was successful
ci/woodpecker/pr/ci-manifests-test Pipeline was successful
REN-802 step 1. Adds:
- infrastructure/post-crds/mqtt-ca.yaml: private MQTT CA (self-signed root
  in cert-manager ns) and ClusterIssuer mqtt-ca.
- apps/home-assistant/mosquitto-dynsec-test.yaml: throwaway mosquitto 2.0.22
  with the dynsec plugin, mTLS listener (require_certificate,
  use_identity_as_username), initContainer that loads Secret
  mqtt-dynsec-seed or a static base file. ClusterIP only; not labelled
  mosquitto, so prod Services and the world-ingress policy do not select it.
- apps/home-assistant/mqtt-account-controller.yaml: ServiceAccount, RBAC
  (cluster-wide list certificates; certificates in home-assistant; secrets
  by resourceName only), controller client cert CN mqtt-account-controller,
  Deployment main-47213ef pointed at the test broker.
- apps/home-assistant/mqtt-accounts.yaml: register with two cert test
  accounts, delivered as ConfigMap mqtt-accounts.

The production broker is not changed.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-06 15:23:36 +00:00
security-bot 6a1546e49c chore(image-automation): bump gitea.renner.uno/k.renner/shelly-manager:build.1791298739
Updates managed by image-automation-controller.
2026-10-06 15:21:28 +00:00
security-bot c41b751596 chore(image-automation): bump gitea.renner.uno/konairius/paperclip:build.1791297080@sha256:0764e882521410d8ce8ed1359f8a1aa64eaa7746aa909653ef70050c239ca195
ci/woodpecker/cron/alert-monitor Pipeline was successful
Updates managed by image-automation-controller.
2026-10-06 14:47:22 +00:00
argus-bot (Paperclip service account) d86e07081a Merge pull request 'chore(paperclip): remove the one-shot lease receipt repair Job (REN-841)' (#1156) from atlas/ren-841-remove-repair-job into master
ci/woodpecker/cron/issue-fix Pipeline was successful
ci/woodpecker/cron/alert-monitor Pipeline was successful
2026-10-06 14:38:49 +00:00
atlas-botandClaude Opus 5.5 85614fb41b chore(paperclip): remove the one-shot lease receipt repair Job (REN-841)
ci/woodpecker/pr/ci-manifests-test Pipeline was successful
ci/woodpecker/pr/ci-scripts-test Pipeline was successful
ci/woodpecker/pr/pr-review Pipeline was successful
The Job ran once (UPDATE 2, leases f06b9278 and f6090b45).

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-06 14:32:13 +00:00
argus-bot (Paperclip service account) 293b86a10d Merge pull request 'fix(paperclip): k8s plugin returns a termination receipt (REN-841)' (#1155) from atlas/ren-841-k8s-plugin-termination-receipt into master
ci/woodpecker/push/build-ci-images Pipeline was successful
ci/woodpecker/push/build-paperclip Pipeline was successful
2026-10-06 14:30:54 +00:00
argus-bot (Paperclip service account) 53bc71737d Merge pull request 'fix(paperclip): one-shot Job to record lease termination receipts (REN-841)' (#1154) from atlas/ren-841-lease-receipt-repair into master
ci/woodpecker/cron/alert-monitor Pipeline was successful
2026-10-06 14:28:17 +00:00
security-bot 57c6fa43bc chore(image-automation): bump gitea.renner.uno/k.renner/shelly-manager:build.1791295339
Updates managed by image-automation-controller.
2026-10-06 14:21:28 +00:00
atlas-botandClaude Opus 5.5 abc09ac722 fix(paperclip): k8s plugin returns a termination receipt (REN-841)
ci/woodpecker/pr/ci-scripts-test Pipeline was successful
ci/woodpecker/pr/pr-review Pipeline was successful
The kubernetes sandbox plugin's release and destroy hooks returned void,
so no lease got a termination receipt and every cancelled pod run left
its card waiting on remote_cleanup. Return state destroyed once the
Sandbox CR / Job (and pod) reads 404, within 20 s; otherwise no receipt.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-06 13:57:41 +00:00
atlas-botandClaude Opus 5.5 ce80a15ab4 fix(paperclip): one-shot Job to record lease termination receipts (REN-841)
ci/woodpecker/pr/ci-scripts-test Pipeline was successful
ci/woodpecker/pr/pr-review Pipeline was successful
ci/woodpecker/pr/ci-manifests-test Pipeline was successful
The kubernetes sandbox plugin returns no termination receipt, so the
leases of cancelled runs e08976cd (REN-837) and 144ae3bf (REN-825) were
released without one and the queued owner comments wait on
remote_cleanup forever. The controller log shows both Sandbox CRs
deleted. Write the missing receipt for exactly those leases.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-06 13:55:01 +00:00
argus-bot (Paperclip service account) 53d4ab34fb Merge pull request 'openbao: suspend mosquitto open3e-int rotator (REN-802)' (#1153) from atlas/ren-802-suspend-open3e-int-rotator into master
ci/woodpecker/cron/issue-fix Pipeline was successful
ci/woodpecker/cron/alert-monitor Pipeline was successful
2026-10-06 13:17:20 +00:00
atlas-botandClaude Opus 5.5 e677986f3e openbao: suspend mosquitto open3e-int rotator (REN-802)
ci/woodpecker/pr/ci-scripts-test Pipeline was successful
ci/woodpecker/pr/pr-review Pipeline was successful
ci/woodpecker/pr/ci-manifests-test Pipeline was successful
The quarterly rotation on 2026-12-01 would change the broker password while
the ESP32 gateway keeps the old one, taking it offline.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-06 13:11:48 +00:00
argus-bot (Paperclip service account) fdab588333 Merge pull request 'home-assistant: remove open3e room setpoint read Job (REN-826)' (#1152) from atlas/ren-826-remove-read-job into master
ci/woodpecker/cron/e2e Pipeline failed
ci/woodpecker/cron/security-scan Pipeline was successful
ci/woodpecker/cron/issue-fix Pipeline was successful
ci/woodpecker/cron/alert-monitor Pipeline was successful
2026-10-06 11:46:44 +00:00
atlas-botandClaude Opus 5.5 8eca50d83e home-assistant: remove open3e room setpoint read Job (REN-826)
ci/woodpecker/pr/ci-scripts-test Pipeline was successful
ci/woodpecker/pr/pr-review Pipeline was successful
ci/woodpecker/pr/ci-manifests-test Pipeline was successful
The one-off read ran (2026-10-06 11:36-11:37 UTC); the result is on REN-826.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-06 11:38:52 +00:00
argus-bot (Paperclip service account) 3a9686400d Merge pull request 'home-assistant: one-off read of open3e Room<N> DIDs 1884-1943 (REN-826)' (#1151) from atlas/ren-826-room-setpoint-read into master
ci/woodpecker/cron/issue-fix Pipeline was successful
ci/woodpecker/cron/alert-monitor Pipeline was successful
2026-10-06 11:34:52 +00:00
atlas-botandClaude Opus 5.5 6c38c88ce4 home-assistant: one-off read of open3e Room<N> DIDs 1884-1943 (REN-826)
ci/woodpecker/pr/ci-scripts-test Pipeline was successful
ci/woodpecker/pr/pr-review Pipeline was successful
ci/woodpecker/pr/ci-manifests-test Pipeline was successful
One-shot Job that sends three read commands on open3e/cmnd to edge-1's
running open3e (read-json + read-raw on 0x6c3, one read-json on 0x6e0)
and prints the replies for Loki. No write mode, no config change.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-06 11:24:27 +00:00
argus-bot (Paperclip service account) a3b53ac798 Merge pull request 'home-assistant: remove open3e FBH capture Job (REN-809)' (#1150) from atlas/ren-809-remove-capture into master
ci/woodpecker/cron/alert-monitor Pipeline was successful
2026-10-06 10:59:09 +00:00
atlas-botandClaude Opus 5.5 fe1bc81bfd home-assistant: remove open3e FBH capture Job (REN-809)
ci/woodpecker/pr/ci-scripts-test Pipeline was successful
ci/woodpecker/pr/pr-review Pipeline was successful
ci/woodpecker/pr/ci-manifests-test Pipeline was successful
The capture answered REN-805 after 24 min (no setpoint in bytes 42-56);
the owner stopped the remaining 24 h window. Flux prune deletes the Job
and its pod.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-06 10:57:07 +00:00
argus-bot (Paperclip service account) 7b7c685a8f Merge pull request 'home-assistant: one-off 24 h read-only open3e FBH payload capture (REN-809)' (#1149) from atlas/ren-809-open3e-fbh-capture into master
ci/woodpecker/cron/issue-fix Pipeline was successful
ci/woodpecker/cron/alert-monitor Pipeline was successful
2026-10-06 10:30:25 +00:00
atlas-botandClaude Opus 5.5 5e473af8b6 home-assistant: match spelled-out ZigBee index in FBH capture filter (REN-812)
ci/woodpecker/pr/ci-scripts-test Pipeline was successful
ci/woodpecker/pr/pr-review Pipeline was successful
ci/woodpecker/pr/ci-manifests-test Pipeline was successful
open3e names the topics ..._ZigBeeSixDeviceCurrentValues, so the
[0-9]+ pattern matched none of the 18 DIDs (Argus review 1437).

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-06 10:24:53 +00:00
atlas-botandClaude Opus 5.5 eca02a384c home-assistant: one-off 24 h read-only capture of FBH ZigBee payloads (REN-809)
ci/woodpecker/pr/ci-scripts-test Pipeline was successful
ci/woodpecker/pr/pr-review Pipeline was successful
ci/woodpecker/pr/ci-manifests-test Pipeline was successful
Job subscribes to open3e/+ as the read-only evcc broker user and prints the
18 One Base FBH ZigBee<N>DeviceCurrentValues messages with a UTC timestamp
to stdout (Loki). Ends after 24 h via mosquitto_sub -W.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-06 10:20:05 +00:00
security-bot a0d2167f95 chore(image-automation): bump gitea.renner.uno/k.renner/shelly-manager:build.1791267662
ci/woodpecker/cron/issue-fix Pipeline was successful
ci/woodpecker/cron/alert-monitor Pipeline was successful
Updates managed by image-automation-controller.
2026-10-06 06:51:27 +00:00
argus-bot (Paperclip service account) a9798b7b9a Merge pull request 'chore(woodpecker): remove the one-shot repo 4 re-key Job (REN-772)' (#1147) from atlas/ren-772-remove-rekey-job into master
ci/woodpecker/cron/issue-fix Pipeline was successful
ci/woodpecker/cron/alert-monitor Pipeline was successful
2026-10-06 05:45:57 +00:00
atlas-botandClaude Opus 5.5 9a1a3f65da chore(woodpecker): remove the one-shot repo 4 re-key Job (REN-772)
ci/woodpecker/pr/ci-scripts-test Pipeline was successful
ci/woodpecker/pr/pr-review Pipeline was successful
ci/woodpecker/pr/ci-manifests-test Pipeline was successful
The Job ran: UPDATE 1, length(hash) 64. Flux prunes the completed Job.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-06 05:44:10 +00:00
argus-bot (Paperclip service account) 8d6a26c119 Merge pull request 'fix(woodpecker): one-shot Job to re-key repo 4 hook hash (REN-772)' (#1146) from atlas/ren-772-wp-repo4-rekey into master
ci/woodpecker/cron/issue-fix Pipeline was successful
ci/woodpecker/cron/alert-monitor Pipeline was successful
2026-10-06 05:40:45 +00:00
atlas-botandClaude Opus 5.5 068e7258bb fix(woodpecker): one-shot Job to re-key repo 4 hook hash (REN-772)
ci/woodpecker/pr/ci-scripts-test Pipeline was successful
ci/woodpecker/pr/pr-review Pipeline was successful
ci/woodpecker/pr/ci-manifests-test Pipeline was successful
The authentik-samba-bridge hook token was burned in a run log (REN-729).
Woodpecker 3.18 cannot re-key a repo hash via API, so a one-shot Job
sets a new random repos.hash generated inside Postgres. Remove after run.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-06 05:35:16 +00:00
argus-bot (Paperclip service account) acc092cfd0 Merge pull request 'chore(mdns-relay): restart once to check the v1.9.1 net1 attach' (#1145) from atlas/ren-722-mdns-relay-v191-attach into master
ci/woodpecker/cron/alert-monitor Pipeline was successful
2026-10-06 05:07:42 +00:00
atlas-botandClaude Opus 5.5 60746b5c8b chore(mdns-relay): restart once to check the v1.9.1 net1 attach
ci/woodpecker/pr/ci-scripts-test Pipeline was successful
ci/woodpecker/pr/pr-review Pipeline was successful
ci/woodpecker/pr/ci-manifests-test Pipeline was successful
No pod has attached net1 since cni-plugins-installer moved to
containernetworking/plugins v1.9.1 (#1142). Hestia's verify item: restart
mdns-relay and confirm a 10.2.30.x DHCP lease. Atlas has no cluster write,
so the restart goes through a pod-template annotation.

Refs: REN-722
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-06 05:02:31 +00:00
security-bot 97827f654e chore(image-automation): bump ghcr.io/paperless-ngx/paperless-ngx:3.3.0
ci/woodpecker/cron/issue-fix Pipeline was successful
ci/woodpecker/cron/alert-monitor Pipeline was successful
Updates managed by image-automation-controller.
2026-10-06 04:41:00 +00:00
argus-bot (Paperclip service account) 44d0792b9f Merge pull request 'fix(openbao): RollingUpdate so the 2.7.1 pods roll out (REN-723)' (#1144) from atlas/ren-723-openbao-rolling into master
ci/woodpecker/cron/issue-fix Pipeline was successful
ci/woodpecker/cron/alert-monitor Pipeline was successful
2026-10-06 03:20:26 +00:00
atlas-botandClaude Opus 5.5 c62dae3b24 fix(openbao): roll the StatefulSet with RollingUpdate (REN-723)
ci/woodpecker/pr/ci-manifests-test Pipeline was successful
ci/woodpecker/pr/ci-scripts-test Pipeline was successful
ci/woodpecker/pr/pr-review Pipeline was successful
#1132 staged OpenBao 2.7.1 in the StatefulSet template, but OnDelete
leaves the pods on 2.6.1 until someone deletes them, and no agent holds
pod delete in openbao. The static seal makes OnDelete unnecessary: the
readiness probe (bao status) passes only once a pod is unsealed, so the
controller replaces one pod at a time and waits for each.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-06 03:15:41 +00:00
argus-bot (Paperclip service account) 64042edc03 Merge pull request 'chore(deps): update openbao' (#1132) from renovate/openbao into master
ci/woodpecker/cron/alert-monitor Pipeline was successful
2026-10-06 03:11:39 +00:00
argus-bot (Paperclip service account) efd5191c6d Merge pull request 'fix(multus): cni-plugins-installer to containernetworking/plugins v1.9.1' (#1142) from atlas/ren-722-cni-plugins-installer-v1.9.1 into master
ci/woodpecker/cron/issue-fix Pipeline was successful
ci/woodpecker/cron/alert-monitor Pipeline was successful
ci/woodpecker/cron/wiki-maintenance Pipeline was successful
2026-10-06 00:21:21 +00:00
argus-bot (Paperclip service account) 0531f6451e Merge pull request 'chore(deps): update all non-major dependencies' (#1054) from renovate/all-minor-patch into master
ci/woodpecker/push/build-ci-images Pipeline failed
ci/woodpecker/cron/alert-monitor Pipeline was successful
2026-10-06 00:14:29 +00:00
argus-bot (Paperclip service account) 65df76fd14 Merge pull request 'chore(deps): update home-assistant non-major' (#1129) from renovate/home-assistant-minor-patch into master 2026-10-06 00:09:39 +00:00
argus-bot (Paperclip service account) 3642f9dbb7 Merge pull request 'chore(deps): update multus cni' (#1131) from renovate/multus into master 2026-10-06 00:07:08 +00:00
argus-bot (Paperclip service account) a7bc9887f4 Merge pull request 'fix(jobs): force-recreate mosquitto and otbr bootstrap Jobs on spec change' (#1139) from atlas/ren-722-job-force-annotations into master
ci/woodpecker/cron/issue-fix Pipeline was successful
ci/woodpecker/cron/alert-monitor Pipeline was successful
2026-10-05 21:27:33 +00:00
argus-bot (Paperclip service account) a27ec53be0 Merge pull request 'chore(deps): update influxdb docker tag to v2.9.1' (#1130) from renovate/influxdb into master
ci/woodpecker/cron/alert-monitor Pipeline was successful
2026-10-05 21:15:22 +00:00
atlas-botandClaude Opus 5.5 67caa6e0d1 fix(multus): cni-plugins-installer to containernetworking/plugins v1.9.1
ci/woodpecker/pr/ci-scripts-test Pipeline was successful
ci/woodpecker/pr/pr-review Pipeline was successful
ci/woodpecker/pr/ci-manifests-test Pipeline was successful
Point the installer at cni-plugins:2026-10-05, built from #1140
(plugins v1.5.1 -> v1.9.1). Version comments updated in the installer
and cni-dhcp-daemon.

Refs: REN-722
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-05 19:02:58 +00:00
argus-bot (Paperclip service account) 8cbd3f3d7a Merge pull request 'feat(influxdb): snapshot data PVC before 2.9 upgrade (REN-723)' (#1141) from atlas/ren-723-influxdb-snapshot into master
ci/woodpecker/cron/issue-fix Pipeline was successful
ci/woodpecker/cron/alert-monitor Pipeline was successful
2026-10-05 18:55:03 +00:00
argus-bot (Paperclip service account) 4b786dac5e Merge pull request 'build(cni-plugins): containernetworking/plugins v1.5.1 -> v1.9.1' (#1140) from atlas/ren-722-cni-plugins-v1.9.1 into master
ci/woodpecker/push/build-ci-images Pipeline was successful
2026-10-05 18:55:02 +00:00
atlas-botandClaude Opus 5.5 037163b59e feat(influxdb): snapshot the data PVC before the 2.9 upgrade (REN-723)
ci/woodpecker/pr/ci-manifests-test Pipeline was successful
ci/woodpecker/pr/ci-scripts-test Pipeline was successful
ci/woodpecker/pr/pr-review Pipeline was successful
A VolumeSnapshot of influxdb-influxdb2 on ceph-block-snapclass, to be
merged and ready before homelab #1130 (2.7.4 -> 2.9.1) so the upgrade has
a restore point beyond `influxd downgrade`.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-05 17:16:00 +00:00
atlas-botandClaude Opus 5.5 4d7c06c6cf docs(openbao): note no-downgrade rollout for chart minor bumps (REN-723)
ci/woodpecker/pr/ci-manifests-test Pipeline was successful
ci/woodpecker/pr/ci-scripts-test Pipeline was successful
ci/woodpecker/pr/pr-review Pipeline was successful
Chart 0.30 moves the server 2.6.1 -> 2.7.1. Record the rollout rule
next to the pin: raft snapshot first, OnDelete one pod at a time, undo
by snapshot restore once a pod has run the new server.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-05 17:14:27 +00:00
atlas-botandClaude Opus 5.5 2bfb3d12e2 fix(influxdb): keep API tokens unhashed on 2.9 (REN-723)
ci/woodpecker/pr/ci-scripts-test Pipeline was successful
ci/woodpecker/pr/ci-manifests-test Pipeline was successful
ci/woodpecker/pr/pr-review Pipeline was successful
InfluxDB 2.9 hashes tokens on startup by default. The HA and Grafana
token Jobs read tokens back via `influx auth list`, which returns no
token once hashed, and a downgrade below 2.8 would erase all tokens.
Set INFLUXD_USE_HASHED_TOKENS=false so the 2.9.1 bump stays reversible
with `influxd downgrade 2.4`.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-05 17:14:13 +00:00
atlas-botandClaude Opus 5.5 b6226b483b build(cni-plugins): containernetworking/plugins v1.5.1 -> v1.9.1
ci/woodpecker/pr/ci-scripts-test Pipeline was successful
ci/woodpecker/pr/pr-review Pipeline was successful
Refresh the plugins pin alongside multus v4.3.1 (#1131), as the
cni-plugins-installer.yaml comment asks. SHA256 cross-checked against
upstream's cni-plugins-linux-amd64-v1.9.1.tgz.sha256 asset. The tarball
still ships macvlan, static, host-local and dhcp.

Image only: CI builds cni-plugins:<date>. The DaemonSet tag bump follows
in a separate PR once the image exists.

Refs: REN-722
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-05 17:00:51 +00:00
atlas-botandClaude Opus 5.5 90a547546e fix(multus): re-vendor v4.3.1 thick manifest changes
ci/woodpecker/pr/ci-scripts-test Pipeline was successful
ci/woodpecker/pr/ci-manifests-test Pipeline was successful
ci/woodpecker/pr/pr-review Pipeline was successful
Upstream deployments/multus-daemonset-thick.yml v4.2.4 -> v4.3.1 adds:
- ClusterRole rule: resource.k8s.io resourceclaims, resourceclaims/status,
  resourceslices; get, list (new DRA client)
- terminationGracePeriodSeconds 10 -> 30
- CRD shortName nad

Header comment updated to v4.3.1 (v4.3.1 also has an unsuffixed tag; we
keep -thick to match the manifest).

Refs: REN-722
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-05 17:00:29 +00:00
atlas-botandClaude Opus 5.5 bb0d32898b fix(jobs): force-recreate mosquitto and otbr bootstrap Jobs on spec change
ci/woodpecker/pr/ci-scripts-test Pipeline was successful
ci/woodpecker/pr/pr-review Pipeline was successful
ci/woodpecker/pr/ci-manifests-test Pipeline was successful
Job pod templates are immutable. Without kustomize.toolkit.fluxcd.io/force,
an image bump (Renovate #1129, #1053, #1054) fails the server-side dry-run
and blocks the home-assistant and otbr Kustomizations. Same pattern as the
influxdb token Jobs.

The mosquitto Jobs exit 0 when their Secret exists. The otbr Job now also
exits 0 when the otbr Deployment is scaled to 0 (disabled), instead of
waiting for a pod that never comes and failing; Role gains get on
apps/deployments for that check.

Refs: REN-722
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-05 16:59:32 +00:00
argus-bot (Paperclip service account) aa3ee1d8c8 Merge pull request 'docs(paperclip): Claude connection needs a setup-token value' (#981) from docs/paperclip-claude-token into master
ci/woodpecker/cron/issue-fix Pipeline was successful
ci/woodpecker/cron/alert-monitor Pipeline was successful
2026-10-05 16:55:10 +00:00
argus-bot (Paperclip service account) 732158dcbc Merge pull request 'chore(ci): bump ci-claude image to 2.1.289' (#1134) from ci-image/claude-2.1.289 into master 2026-10-05 16:54:50 +00:00
argus-bot (Paperclip service account) 4caaae1e8c Merge pull request 'matrix-bridge: build.1791195981 (no repeated comments, REN-717)' (#1138) from atlas/ren-717-matrix-bridge-1791195981 into master
ci/woodpecker/cron/issue-fix Pipeline was successful
ci/woodpecker/cron/alert-monitor Pipeline was successful
2026-10-05 13:05:45 +00:00
atlas-botandClaude Opus 5.5 7e18224053 matrix-bridge: build.1791195981 (no repeated comments, REN-717)
ci/woodpecker/pr/ci-scripts-test Pipeline was successful
ci/woodpecker/pr/pr-review Pipeline was successful
ci/woodpecker/pr/ci-manifests-test Pipeline was successful
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-05 13:04:38 +00:00
argus-bot (Paperclip service account) 9352014be3 Merge pull request 'fix(paperclip): add CAP_KILL so tini can forward SIGTERM (REN-702)' (#1137) from atlas/ren-702-paperclip-cap-kill into master
ci/woodpecker/cron/e2e Pipeline failed
ci/woodpecker/cron/security-scan Pipeline was successful
ci/woodpecker/cron/issue-fix Pipeline was successful
ci/woodpecker/cron/alert-monitor Pipeline was successful
2026-10-05 07:18:35 +00:00
atlas-botandClaude Opus 5.5 9824e10e0a fix(paperclip): add CAP_KILL so tini can forward SIGTERM (REN-702)
ci/woodpecker/pr/ci-scripts-test Pipeline was successful
ci/woodpecker/pr/pr-review Pipeline was successful
ci/woodpecker/pr/ci-manifests-test Pipeline was successful
tini (PID 1, root) cannot signal node (uid 1000) without CAP_KILL, exits
with EPERM on every rollout, and the server is killed without its
graceful run drain. In-flight runs are orphaned instead of being
interrupted and retried.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-05 07:10:32 +00:00
argus-bot (Paperclip service account) da1e6fedf0 Merge pull request 'feat(matrix): roll matrix-bridge to build.1791179547 (REN-691)' (#1136) from atlas/ren-691-matrix-bridge-1791179547 into master
ci/woodpecker/cron/issue-fix Pipeline was successful
ci/woodpecker/cron/alert-monitor Pipeline was successful
2026-10-05 05:55:27 +00:00
atlas-botandClaude Opus 5.5 a975f4e8f6 feat(matrix): roll matrix-bridge to build.1791179547 (REN-691)
ci/woodpecker/pr/ci-manifests-test Pipeline is pending
ci/woodpecker/pr/ci-scripts-test Pipeline is pending
ci/woodpecker/pr/pr-review Pipeline is pending
One Matrix room per card labelled 'matrix' (REN-668). Sets
PAPERCLIP_PUBLIC_URL for the card link in the room topic.
Rollback: build.1791177680 and drop the env var.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-05 05:54:02 +00:00
security-bot 5dab2f940e chore(image-automation): bump gitea.renner.uno/konairius/paperclip:build.1791176861@sha256:2f5535f14daf7a30f68f472ad638366260586771524a0fb28c53e62101128234
ci/woodpecker/cron/issue-fix Pipeline was successful
ci/woodpecker/cron/alert-monitor Pipeline was successful
Updates managed by image-automation-controller.
2026-10-05 05:27:11 +00:00
argus-bot (Paperclip service account) f187c31a10 Merge pull request 'feat(matrix): roll matrix-bridge to build.1791177680 (REN-685)' (#1135) from atlas/ren-685-matrix-bridge-1791177680 into master 2026-10-05 05:24:56 +00:00
atlas-botandClaude Opus 5.5 e56f920079 feat(matrix): roll matrix-bridge to build.1791177680 (REN-685)
ci/woodpecker/pr/ci-manifests-test Pipeline is pending
ci/woodpecker/pr/ci-scripts-test Pipeline is pending
ci/woodpecker/pr/pr-review Pipeline is pending
Route agent comments on author account only, from konairius/matrix-bridge#5
(9a83e70, REN-668). No env, secret, port or network change.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-05 05:23:08 +00:00
claude-bot 5ad4c69676 chore(ci): bump ci-claude image to 2.1.289
ci/woodpecker/pr/ci-manifests-test Pipeline was successful
ci/woodpecker/pr/ci-scripts-test Pipeline was successful
ci/woodpecker/pr/pr-review Pipeline was successful
2026-10-05 05:11:33 +00:00
argus-bot (Paperclip service account) 94a2eac559 Merge pull request 'chore(deps): update ci non-major' (#1126) from renovate/ci-minor-patch into master
ci/woodpecker/push/build-ci-images Pipeline was successful
ci/woodpecker/push/build-agent-runtime Pipeline was successful
ci/woodpecker/push/ci-claude-refresh Pipeline was successful
ci/woodpecker/push/deploy-infrastructure Pipeline was successful
ci/woodpecker/cron/alert-monitor Pipeline was successful
ci/woodpecker/push/build-paperclip Pipeline was successful
2026-10-05 05:02:24 +00:00
renovate-bot 1784153656 chore(deps): update openbao
ci/woodpecker/pr/ci-scripts-test Pipeline was successful
ci/woodpecker/pr/ci-manifests-test Pipeline was successful
ci/woodpecker/pr/pr-review Pipeline was successful
2026-10-05 02:01:36 +00:00
renovate-bot b32a5e0747 chore(deps): update multus cni
ci/woodpecker/pr/ci-scripts-test Pipeline was successful
ci/woodpecker/pr/pr-review Pipeline was successful
ci/woodpecker/pr/ci-manifests-test Pipeline was successful
2026-10-05 02:01:34 +00:00
renovate-bot 8b0aaef728 chore(deps): update influxdb docker tag to v2.9.1
ci/woodpecker/pr/ci-scripts-test Pipeline was successful
ci/woodpecker/pr/pr-review Pipeline was successful
ci/woodpecker/pr/ci-manifests-test Pipeline was successful
2026-10-05 02:01:32 +00:00
renovate-bot e1f0aa021f chore(deps): update home-assistant non-major
ci/woodpecker/pr/ci-scripts-test Pipeline was successful
ci/woodpecker/pr/pr-review Pipeline was successful
ci/woodpecker/pr/ci-manifests-test Pipeline was successful
2026-10-05 02:01:31 +00:00
renovate-bot 68c0978660 chore(deps): update all non-major dependencies
ci/woodpecker/pr/ci-scripts-test Pipeline was successful
ci/woodpecker/pr/ci-manifests-test Pipeline was successful
ci/woodpecker/pr/pr-review Pipeline was successful
2026-10-05 02:01:26 +00:00
renovate-bot ed272266fc chore(deps): update ci non-major
ci/woodpecker/pr/ci-scripts-test Pipeline was successful
ci/woodpecker/pr/ci-manifests-test Pipeline was successful
ci/woodpecker/pr/pr-review Pipeline was successful
2026-10-05 02:01:23 +00:00
argus-bot (Paperclip service account) f930971102 Merge pull request 'cilium: chart-native metrics Service, attended helm upgrade (REN-166)' (#1032) from atlas/ren-166-cilium-verdict-metric into master
ci/woodpecker/cron/wiki-maintenance Pipeline was successful
ci/woodpecker/cron/issue-fix Pipeline was successful
ci/woodpecker/cron/alert-monitor Pipeline was successful
ci/woodpecker/cron/e2e Pipeline failed
ci/woodpecker/cron/update-audit Pipeline was successful
2026-10-05 00:01:56 +00:00
argus-bot (Paperclip service account) a3e0a3d5c3 Merge pull request 'feat(matrix): roll matrix-bridge to build.1791152484 (REN-671)' (#1125) from atlas/ren-671-matrix-bridge-1791152484 into master
ci/woodpecker/cron/issue-fix Pipeline was successful
ci/woodpecker/cron/alert-monitor Pipeline was successful
2026-10-04 22:24:44 +00:00
atlas-botandClaude Opus 5.5 3096ad3d80 feat(matrix): roll matrix-bridge to build.1791152484 (REN-671)
ci/woodpecker/pr/ci-scripts-test Pipeline was successful
ci/woodpecker/pr/pr-review Pipeline was successful
ci/woodpecker/pr/ci-manifests-test Pipeline was successful
Housekeeping filter from konairius/matrix-bridge#4 (f1ad2ea5, REN-668).
No env, secret, port or network change.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-04 22:23:14 +00:00
argus-bot (Paperclip service account) 091fc33f86 Merge pull request 'feat(matrix): publish element, matrix and account.matrix publicly (REN-663)' (#1124) from atlas/ren-663-matrix-public into master
ci/woodpecker/cron/alert-monitor Pipeline was successful
2026-10-04 22:07:06 +00:00
atlas-botandClaude Opus 5.5 e579a8f6d3 feat(matrix): publish element, matrix and account.matrix publicly (REN-663)
ci/woodpecker/pr/ci-scripts-test Pipeline was successful
ci/woodpecker/pr/pr-review Pipeline was successful
ci/woodpecker/pr/ci-manifests-test Pipeline was successful
The three Matrix Ingresses had no dns.renner.uno/public label, so
netbird-service-sync never created a NetBird proxy service for them and the
public proxy rejects their SNI (tlsv1 alert internal error). Label them like
audiobooks/immich and add Gatus checks for the three hosts.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-04 22:01:22 +00:00
argus-bot (Paperclip service account) f1e987bdf5 Merge pull request 'feat(matrix): deploy matrix-bridge build.1791062345 (REN-587)' (#1123) from atlas/ren-587-matrix-bridge into master
ci/woodpecker/cron/alert-monitor Pipeline was successful
2026-10-04 21:46:21 +00:00
atlas-botandClaude Opus 5.5 b052fc2576 feat(matrix): generate the appservice tokens in-cluster (REN-587)
ci/woodpecker/pr/ci-scripts-test Pipeline was successful
ci/woodpecker/pr/ci-manifests-test Pipeline was successful
ci/woodpecker/pr/pr-review Pipeline was successful
as_token and hs_token come from an ESO Password generator (CreatedOnce)
instead of OpenBao, so no one has to seed them by hand. Synapse mounts
only the generated Secret and no longer depends on the OpenBao path;
OpenBao homelab/apps/matrix-bridge now holds only paperclip_api_key.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-04 21:45:07 +00:00
atlas-botandClaude Opus 5.5 9093b52e00 feat(matrix): deploy matrix-bridge build.1791062345 as a Synapse appservice (REN-587)
ci/woodpecker/pr/ci-scripts-test Pipeline was successful
ci/woodpecker/pr/pr-review Pipeline was canceled
ci/woodpecker/pr/ci-manifests-test Pipeline was canceled
Adds the matrix-bridge Deployment, Service and ExternalSecret in the
matrix namespace, loads its appservice registration in Synapse, and opens
the bridge -> Paperclip API path (:3100) in both namespaces' policies.
Tokens and the board key come from OpenBao homelab/apps/matrix-bridge.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-04 21:41:10 +00:00
argus-bot (Paperclip service account) c384a052a9 Merge pull request 'fix(authentik): allow authorization_code for matrix-mas (REN-567)' (#1122) from atlas/ren-567-authentik-grant-types into master
ci/woodpecker/cron/issue-fix Pipeline was successful
ci/woodpecker/cron/alert-monitor Pipeline was successful
2026-10-04 21:20:51 +00:00
atlas-botandClaude Opus 5.5 e2e45b2b86 fix(authentik): allow authorization_code for matrix-mas (REN-567)
ci/woodpecker/pr/ci-scripts-test Pipeline was successful
ci/woodpecker/pr/pr-review Pipeline was successful
ci/woodpecker/pr/ci-manifests-test Pipeline was successful
Authentik 2026.5 checks each authorize against the provider's
grant_types, and a provider created by a blueprint starts with an empty
list. Every Matrix login through Authentik failed with invalid_request
(log: "Invalid grant_type for provider", grant_type=authorization_code).

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-04 21:19:26 +00:00
argus-bot (Paperclip service account) 564e6abcaa Merge pull request 'feat(matrix): MAS with Authentik passkey login and QR sign-in (REN-567)' (#1121) from atlas/ren-567-mas into master
ci/woodpecker/cron/alert-monitor Pipeline was successful
2026-10-04 20:51:03 +00:00
atlas-botandClaude Opus 5.5 bfc3bbc190 feat(matrix): Element Web QR sign-in on the welcome page (REN-567)
ci/woodpecker/pr/ci-scripts-test Pipeline was successful
ci/woodpecker/pr/ci-manifests-test Pipeline was successful
ci/woodpecker/pr/pr-review Pipeline was successful
Owner wants QR sign-in from the desktop app as well. Linking a phone from
a signed-in Element (Link new device) only needs the server side from the
previous commit (MSC4108 + MAS device-code grant). This flag also lets a
new browser sign in by QR.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-04 20:11:32 +00:00
atlas-botandClaude Opus 5.5 b17001d6da feat(matrix): MAS with Authentik passkey login and QR sign-in (REN-567)
ci/woodpecker/pr/ci-scripts-test Pipeline was successful
ci/woodpecker/pr/pr-review Pipeline was canceled
ci/woodpecker/pr/ci-manifests-test Pipeline was canceled
Element X signs in only with a password or through MAS. Put MAS in front
of Synapse with Authentik (passkey) as the upstream provider, and enable
the QR rendezvous (MSC4108/MSC4388).

- apps/matrix/mas.yaml: MAS 1.26.0, `mas` database in mx-pg (CNPG
  Database), account.matrix.renner.uno.
- synapse.yaml: matrix_authentication_service, password_config off; a
  syn2mas init container moves the existing accounts and sessions once
  (marker on synapse-data).
- Drop the owner-account Job; MAS owns accounts now.
- Authentik: public PKCE client `matrix-mas`, passkey flows, only the
  Matrix Users group (k.renner).
- matrix-ns: MAS egress to Traefik :8443 (auth.renner.uno) only.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-04 20:08:04 +00:00
argus-bot (Paperclip service account) c96f8d0282 Merge pull request 'feat(matrix): Synapse homeserver + Element Web, private, no federation (REN-567)' (#1112) from atlas/ren-567-matrix into master
ci/woodpecker/cron/issue-fix Pipeline was successful
ci/woodpecker/cron/alert-monitor Pipeline was successful
2026-10-04 19:43:36 +00:00
argus-bot (Paperclip service account) daa6f810a0 Merge pull request 'network-policies: paperclip agents → edge-1 SSH 10.2.30.108:22 (REN-627)' (#1120) from atlas/ren-627-edge1-ssh-egress into master
ci/woodpecker/cron/alert-monitor Pipeline was successful
ci/woodpecker/cron/issue-fix Pipeline was successful
2026-10-04 15:24:30 +00:00
atlas-botandClaude Opus 5.5 d04546382d network-policies: let paperclip agents reach edge-1 SSH on 10.2.30.108:22 (REN-627)
ci/woodpecker/pr/ci-scripts-test Pipeline was successful
ci/woodpecker/pr/pr-review Pipeline was successful
ci/woodpecker/pr/ci-manifests-test Pipeline was successful
Scoped access for the zwave-js restart (REN-628): forced-command user
atlas-zwave on edge-1. One /32, TCP 22 only.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-04 15:19:06 +00:00
argus-bot (Paperclip service account) 573bd670d5 Merge pull request 'monitoring: GET-only Loki read gateway for the paperclip read SA (REN-621)' (#1119) from atlas/ren-621-loki-read-gateway into master
ci/woodpecker/cron/issue-fix Pipeline was successful
ci/woodpecker/cron/alert-monitor Pipeline was successful
2026-10-04 12:22:00 +00:00
atlas-botandClaude Opus 5.5 fe2e163b6a monitoring: GET-only Loki read gateway for the paperclip read SA (REN-621)
ci/woodpecker/pr/ci-scripts-test Pipeline was successful
ci/woodpecker/pr/pr-review Pipeline was successful
ci/woodpecker/pr/ci-manifests-test Pipeline was successful
Loki runs SingleBinary with auth disabled and answers GET on
/ingester/shutdown and /flush, so an RBAC `get` on services/proxy for
loki:3100 would not be read-only. Put an nginx allow-list in front of it
(query, query_range, labels, label/<name>/values, series; GET only;
upstream URI rebuilt per location) and grant the paperclip read SA
`get` on that Service only. Owner decision: REN-622 (option A2).

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-04 12:20:27 +00:00
argus-bot (Paperclip service account) f7c143d4a3 Merge pull request 'paperclip: raise pclp-pg memory to 1Gi/2Gi (REN-603)' (#1118) from atlas/ren-603-pclp-pg-memory into master
ci/woodpecker/cron/issue-fix Pipeline was successful
ci/woodpecker/cron/e2e Pipeline failed
ci/woodpecker/cron/security-scan Pipeline was successful
ci/woodpecker/cron/alert-monitor Pipeline was successful
2026-10-04 05:05:51 +00:00
atlas-botandClaude Opus 5.5 1cfd529d5d paperclip: raise pclp-pg memory to 1Gi/2Gi (REN-603)
ci/woodpecker/pr/ci-scripts-test Pipeline was successful
ci/woodpecker/pr/pr-review Pipeline was successful
ci/woodpecker/pr/ci-manifests-test Pipeline was successful
The primary pclp-pg-2 was OOMKilled 6 times on 3-4 Oct at the 1Gi
limit. Each kill drops Paperclip's DB and fails in-flight agent runs.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-04 05:04:33 +00:00
argus-bot (Paperclip service account) d9c698609d Merge pull request 'review-bot: GITEA_VERIFY_REPO to konairius/shelly-manager (REN-528)' (#1106) from atlas/ren-528-review-bot-verify-repo into master
ci/woodpecker/cron/e2e Pipeline failed
ci/woodpecker/cron/wiki-maintenance Pipeline was successful
ci/woodpecker/cron/issue-fix Pipeline was successful
ci/woodpecker/cron/alert-monitor Pipeline was successful
2026-10-04 00:10:55 +00:00
argus-bot (Paperclip service account) a201100799 Merge pull request 'cilium: enable Hubble relay for paperclip (REN-487)' (#1102) from atlas/ren-487-hubble-relay into master 2026-10-04 00:07:02 +00:00
security-bot 0b1df0af40 chore(image-automation): bump gitea.renner.uno/konairius/paperclip:build.1791063392@sha256:44887a2a95b567ea6847609662964c3056b9721c924f943770a550570cabd9b4
ci/woodpecker/cron/issue-fix Pipeline was successful
ci/woodpecker/cron/alert-monitor Pipeline was successful
Updates managed by image-automation-controller.
2026-10-03 21:57:02 +00:00
argus-bot (Paperclip service account) 77c8566c5b Merge pull request 'gitea: keep volumeName on data-gitea-0 so the 60Gi apply passes (REN-583, fixes #1116)' (#1117) from atlas/ren-583-gitea-pvc-volumename into master
ci/woodpecker/cron/issue-fix Pipeline was successful
ci/woodpecker/cron/alert-monitor Pipeline was successful
2026-10-03 21:30:32 +00:00
atlas-botandClaude Opus 5.5 d2ee7a097c gitea: keep volumeName on the data-gitea-0 PVC so the 60Gi apply passes (REN-583)
ci/woodpecker/pr/ci-scripts-test Pipeline was successful
ci/woodpecker/pr/pr-review Pipeline was successful
ci/woodpecker/pr/ci-manifests-test Pipeline failed
#1116 left spec.volumeName out of pvc.yaml. kustomize-controller has owned
that field since the namespace move pre-created the claim (eb23d3ac), so
server-side apply tried to clear it and the API server rejected the claim
as an immutable-spec change. The gitea Kustomization is Ready=False and the
claim stays at 40Gi. Pin volumeName to the live value.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-03 21:29:21 +00:00
argus-bot (Paperclip service account) 4de7b0c49b Merge pull request 'gitea: grow data volume 40Gi -> 60Gi via Flux-owned PVC, add low-space alert (REN-583)' (#1116) from atlas/ren-583-gitea-volume-60gi into master 2026-10-03 21:26:21 +00:00
atlas-botandClaude Opus 5.5 433719bfc0 gitea: grow data volume 40Gi -> 60Gi via a Flux-owned PVC, add low-space alert (REN-583)
ci/woodpecker/pr/ci-scripts-test Pipeline was successful
ci/woodpecker/pr/pr-review Pipeline was successful
ci/woodpecker/pr/ci-manifests-test Pipeline failed
The volume filled on REN-580. volumeClaimTemplates is immutable, so own the
live claim data-gitea-0 in apps/gitea/pvc.yaml (prune disabled) and let Flux
server-side apply grow it; ceph-block expands online. Add GiteaDataVolumeLow
(<25% free for 15m) with a promtool suite and two mutation controls.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-03 21:16:14 +00:00
argus-bot (Paperclip service account) b5f54ad069 Merge pull request 'paperclip: resume Claude sessions across runs with a managed AI home (REN-563)' (#1115) from atlas/ren-563-claude-session-resume into master
ci/woodpecker/cron/alert-monitor Pipeline was successful
ci/woodpecker/push/build-ci-images Pipeline was successful
ci/woodpecker/push/build-paperclip Pipeline was successful
2026-10-03 20:43:50 +00:00
atlas-botandClaude Opus 5.5 8d894e466e paperclip: resume Claude sessions across runs with a managed AI home (REN-563)
ci/woodpecker/pr/ci-scripts-test Pipeline was successful
ci/woodpecker/pr/pr-review Pipeline was successful
Stable session fingerprint for the per-run managed AI home paths, plus a
persistent CLAUDE_CONFIG_DIR/projects so the resumed session finds its
transcript. Local runs only. Fix-forward of #1111 (reverted in #1113).

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-03 20:41:11 +00:00
security-bot 7a9f42a728 chore(image-automation): bump gitea.renner.uno/konairius/paperclip:build.1791058212@sha256:bdb6933fe5d1c790550705867b93900c9e49df84cd1aa253305f5e8692d5292d
ci/woodpecker/cron/alert-monitor Pipeline was successful
ci/woodpecker/cron/issue-fix Pipeline was successful
Updates managed by image-automation-controller.
2026-10-03 20:27:02 +00:00
argus-bot (Paperclip service account) a0ed9c0d17 Merge pull request 'Revert #1111: ACPX resume fails because Claude transcript is per-run (REN-563)' (#1113) from atlas/ren-563-revert-1111 into master
ci/woodpecker/push/build-ci-images Pipeline was successful
ci/woodpecker/cron/alert-monitor Pipeline was successful
ci/woodpecker/push/build-paperclip Pipeline was successful
2026-10-03 20:09:33 +00:00
atlas-botandClaude Opus 5.5 f68ac16137 Revert "paperclip: keep per-run managed AI home out of ACPX session fingerprint (REN-563)"
ci/woodpecker/pr/ci-scripts-test Pipeline was successful
ci/woodpecker/pr/pr-review Pipeline was successful
This reverts #1111 (3f3305cf). With the fingerprint stable, the ACPX engine
now resumes the previous Claude session, but the Claude transcript lives in
the per-run CLAUDE_CONFIG_DIR, which the server deletes after each run. acpx
uses resumePolicy same-session-only for persistent sessions, so the turn
fails ("Persistent ACP session ... could not be resumed: Resource not
found") instead of falling back to a fresh session (run 12a2a911).

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-03 20:08:28 +00:00
security-bot a1e1fee9e0 chore(image-automation): bump gitea.renner.uno/konairius/paperclip:build.1791054619@sha256:df5d4ba55c8f0dc020ffb4faf87194b3e1b1df3076b4fde14bae20c860af9500
ci/woodpecker/cron/issue-fix Pipeline was successful
ci/woodpecker/cron/alert-monitor Pipeline was successful
Updates managed by image-automation-controller.
2026-10-03 19:27:01 +00:00
atlas-botandClaude Opus 5.5 04bda0d7c2 feat(matrix): Synapse homeserver + Element Web, private, no federation (REN-567)
ci/woodpecker/pr/ci-manifests-test Pipeline failed
ci/woodpecker/pr/ci-scripts-test Pipeline was successful
ci/woodpecker/pr/pr-review Pipeline was successful
New `matrix` namespace and Flux KS: Synapse v1.162.0 on a CNPG Postgres
(mx-pg, Barman to Hetzner), media store + signing key on synapse-data
(Velero matrix-daily), Element Web locked to matrix.renner.uno, and an
idempotent Job that creates the one owner account from OpenBao
apps/matrix. Federation off, registration and guests closed, LAN-only
ingress, egress limited to the in-cluster DB and the push gateway.
Appservice slot left empty for REN-565 Part 2.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-03 19:15:11 +00:00
argus-bot (Paperclip service account) 3f3305cf01 Merge pull request 'paperclip: keep per-run managed AI home out of ACPX session fingerprint (REN-563)' (#1111) from atlas/ren-563-acpx-session-resume into master
ci/woodpecker/push/build-ci-images Pipeline was successful
ci/woodpecker/push/build-paperclip Pipeline was successful
ci/woodpecker/cron/alert-monitor Pipeline was successful
2026-10-03 19:09:54 +00:00
atlas-botandClaude Opus 5.5 01ed3ca20d paperclip: keep per-run managed AI home out of ACPX session fingerprint (REN-563)
ci/woodpecker/pr/ci-scripts-test Pipeline was successful
ci/woodpecker/pr/pr-review Pipeline was successful
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-03 19:06:50 +00:00
security-bot fd59c81bf4 chore(image-automation): bump gitea.renner.uno/konairius/paperclip:build.1791047004@sha256:36744031bb1b217c64dc72a79c49ecdf021e25961e757d26afedfbfb494a9860
ci/woodpecker/cron/issue-fix Pipeline was successful
ci/woodpecker/cron/alert-monitor Pipeline was successful
Updates managed by image-automation-controller.
2026-10-03 17:27:01 +00:00
security-bot 9667c76b4c chore(image-automation): bump gitea.renner.uno/k.renner/shelly-manager:build.1791047765
Updates managed by image-automation-controller.
2026-10-03 17:21:19 +00:00
argus-bot (Paperclip service account) 4b11802e86 Merge pull request 'paperclip: rotate agent-argus SA token Secret via rename to -v3 (REN-544)' (#1110) from atlas/ren-544-argus-token-v3 into master
ci/woodpecker/cron/alert-monitor Pipeline was successful
2026-10-03 17:10:00 +00:00
atlas-botandClaude Opus 5.5 ccb755ba38 paperclip: rotate agent-argus SA token Secret via rename to -v3 (REN-544)
ci/woodpecker/pr/ci-manifests-test Pipeline failed
ci/woodpecker/pr/ci-scripts-test Pipeline was successful
ci/woodpecker/pr/pr-review Pipeline was successful
The -v2 token leaked into Argus run d2eede8a (REN-542). Renaming makes the
token controller mint a new token; Flux prunes the old Secret, which
invalidates the leaked token.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-03 17:08:19 +00:00
argus-bot (Paperclip service account) 997e11ce19 Merge pull request 'fix(paperclip): rotate agent-atlas SA token Secret to -v3 (REN-539)' (#1109) from atlas/ren-539-atlas-token-v3 into master 2026-10-03 17:04:06 +00:00
argus-bot (Paperclip service account) f12193624e Merge pull request 'feat(paperclip): keep Claude auto memory in AGENT_HOME (REN-541)' (#1108) from atlas/ren-541-claude-auto-memory into master
ci/woodpecker/push/build-ci-images Pipeline was successful
ci/woodpecker/push/build-paperclip Pipeline was successful
2026-10-03 17:02:56 +00:00
argus-bot (Paperclip service account) d6ce8bdf1f Merge pull request 'paperclip: rotate agent-hestia SA token Secret via rename to -v3 (REN-540)' (#1107) from atlas/ren-540-hestia-token-v3 into master
ci/woodpecker/cron/alert-monitor Pipeline was successful
2026-10-03 16:59:22 +00:00
atlas-botandClaude Opus 5.5 856fc28866 fix(paperclip): rotate agent-atlas SA token Secret to -v3 (REN-539)
ci/woodpecker/pr/ci-manifests-test Pipeline failed
ci/woodpecker/pr/ci-scripts-test Pipeline was successful
ci/woodpecker/pr/pr-review Pipeline was successful
The agent-atlas-token-v2 token leaked in an Atlas run log (REN-536).
Rename the Secret to -v3 so Flux prunes -v2 and the token controller
issues a new token; update the agent-token-read resourceNames entry.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-03 16:48:32 +00:00
atlas-botandClaude Opus 5.5 5a77a30c18 feat(paperclip): keep Claude auto memory in AGENT_HOME (REN-541)
ci/woodpecker/pr/ci-scripts-test Pipeline was successful
ci/woodpecker/pr/pr-review Pipeline was successful
Claude auto memory defaults to $CLAUDE_CONFIG_DIR/projects/<p>/memory.
Paperclip makes CLAUDE_CONFIG_DIR fresh per run and deletes it, so every
memory is lost. New image patch: the ACPX engine writes
autoMemoryDirectory=<AGENT_HOME>/memory into the per-run
.claude/settings.local.json. AGENT_HOME is restored and saved around each
run, local and in k8s pods. Not part of the session fingerprint, so
resume is unchanged.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-03 16:46:18 +00:00
atlas-botandClaude Opus 5.5 f835f40eb7 paperclip: rotate agent-hestia SA token Secret via rename to -v3 (REN-540)
ci/woodpecker/pr/ci-scripts-test Pipeline was successful
ci/woodpecker/pr/pr-review Pipeline was successful
ci/woodpecker/pr/ci-manifests-test Pipeline failed
The token leaked into Hestia run 13bd8a68 (REN-535). Renaming makes the
token controller mint a new token; Flux prunes the old Secret, which
invalidates the leaked token.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-03 16:39:31 +00:00
atlas-botandClaude Opus 5.5 427b98948e review-bot: verify against konairius/shelly-manager after repo move (REN-528)
ci/woodpecker/pr/ci-scripts-test Pipeline was successful
ci/woodpecker/pr/pr-review Pipeline was successful
ci/woodpecker/pr/ci-manifests-test Pipeline failed
GITEA_VERIFY_REPO still named k.renner/shelly-manager, which now
answers 307 to the new path. Point it at the new path directly.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-03 16:34:20 +00:00
argus-bot (Paperclip service account) e553c37cb3 Merge pull request 'feat(monitoring): blackbox-http probe for shelly-manager /health (REN-533)' (#1105) from atlas/ren-533-shelly-manager-probe into master
ci/woodpecker/cron/issue-fix Pipeline was successful
ci/woodpecker/cron/alert-monitor Pipeline was successful
2026-10-03 16:30:50 +00:00
atlas-botandClaude Opus 5.5 6649e5b560 feat(monitoring): blackbox-http probe for shelly-manager /health (REN-533)
ci/woodpecker/pr/ci-scripts-test Pipeline was successful
ci/woodpecker/pr/pr-review Pipeline was successful
ci/woodpecker/pr/ci-manifests-test Pipeline failed
In-cluster app-health target via the ClusterIP Service, so a dead app
behind the live shelly-manager-gate outpost no longer reads green.
Covered by the existing BlackboxProbeFailing rule; no CNP change needed
(home-assistant default-deny already admits the monitoring namespace).

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-03 16:29:05 +00:00
security-bot 0d9d6b3c97 chore(image-automation): bump gitea.renner.uno/k.renner/shelly-manager:build.1791038995
ci/woodpecker/cron/issue-fix Pipeline was successful
ci/woodpecker/cron/alert-monitor Pipeline was successful
Updates managed by image-automation-controller.
2026-10-03 15:21:19 +00:00
argus-bot (Paperclip service account) 2d8191efdd Merge pull request 'paperclip: rotate agent-argus SA token Secret via rename (REN-525)' (#1104) from atlas/ren-525-rotate-argus-token into master
ci/woodpecker/cron/alert-monitor Pipeline was successful
2026-10-03 15:04:00 +00:00
atlas-botandClaude Opus 5.5 8f98d267c6 paperclip: rotate agent-argus SA token Secret via rename (REN-525)
ci/woodpecker/pr/ci-scripts-test Pipeline was successful
ci/woodpecker/pr/pr-review Pipeline was successful
ci/woodpecker/pr/ci-manifests-test Pipeline failed
The token leaked into Argus run 373367ed (REN-523). Renaming makes the
token controller mint a new token; Flux prunes the old Secret, which
invalidates the legacy token.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-03 14:46:26 +00:00
argus-bot (Paperclip service account) 080ef16b9d Merge pull request 'paperclip: rotate agent-hestia/hermes/atlas SA tokens via rename (REN-509)' (#1103) from atlas/ren-509-rotate-agent-tokens into master
ci/woodpecker/cron/e2e Pipeline failed
ci/woodpecker/cron/security-scan Pipeline was successful
ci/woodpecker/cron/issue-fix Pipeline was successful
ci/woodpecker/cron/alert-monitor Pipeline was successful
2026-10-03 06:39:03 +00:00
atlas-botandClaude Opus 5.5 a59810d351 paperclip: rotate agent-hestia/hermes/atlas SA token Secrets via rename (REN-509)
ci/woodpecker/pr/ci-scripts-test Pipeline was successful
ci/woodpecker/pr/pr-review Pipeline was successful
ci/woodpecker/pr/ci-manifests-test Pipeline failed
The three tokens leaked into run logs (REN-483, REN-484, REN-507).
Renaming makes the token controller mint new tokens; Flux prunes the
old Secrets, which invalidates the legacy tokens.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-03 06:36:55 +00:00
atlas-botandClaude Opus 5.5 dc669f9f06 hubble-relay CNP: limit node ingress to the :4222 probe port
ci/woodpecker/pr/ci-scripts-test Pipeline was successful
ci/woodpecker/pr/ci-manifests-test Pipeline was successful
ci/woodpecker/pr/pr-review Pipeline was successful
The host/remote-node rule had no toPorts, so any node or hostNetwork pod
could reach the relay's unauthenticated gRPC on :4245. Restrict it to the
kubelet gRPC probe port (chart deployment.yaml probes use port 4222).

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-03 00:15:00 +00:00
atlas-botandClaude Opus 5.5 8a863fbbd7 monitoring: drop line-number citation of upstream ESO values.yaml (REN-487)
ci/woodpecker/pr/ci-scripts-test Pipeline was successful
ci/woodpecker/pr/ci-manifests-test Pipeline was successful
ci/woodpecker/pr/pr-review Pipeline was successful
yaml-citations failed on external-secrets-podmonitor.yaml:35, which cited the
upstream chart's values.yaml by line. That file is not in the repo, so no
path#anchor form exists; name the keys instead. Comment-only change.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-03 00:07:29 +00:00
atlas-botandClaude Opus 5.5 8f736eb217 cilium: enable Hubble relay, reachable from the paperclip pod only (REN-487)
ci/woodpecker/pr/ci-scripts-test Pipeline was successful
ci/woodpecker/pr/ci-manifests-test Pipeline failed
ci/woodpecker/pr/pr-review Pipeline was successful
Hubble is already on in every agent; the relay gives one gRPC endpoint so
`hubble observe -n paperclip-renner --verdict DROPPED` runs without exec
into kube-system. The chart renders no change to cilium-config or the agent
DaemonSet, so the reloader does not roll the CNI.

The relay has no client auth: a new CNP admits only the paperclip pod (and
nodes for probes), and paperclip-egress gains the matching :4245 rule.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-02 22:37:19 +00:00
argus-bot (Paperclip service account) bb94b49b6b Merge pull request 'agent-runtime-go: add govulncheck (REN-488)' (#1101) from atlas/ren-488-govulncheck into master
ci/woodpecker/push/build-ci-images Pipeline was successful
ci/woodpecker/push/build-agent-runtime Pipeline was successful
ci/woodpecker/cron/wiki-maintenance Pipeline was successful
ci/woodpecker/cron/issue-fix Pipeline was successful
ci/woodpecker/cron/alert-monitor Pipeline was successful
2026-10-02 21:00:31 +00:00
atlas-botandClaude Opus 5.5 54d135c56a agent-runtime-go: add govulncheck v1.8.0 (REN-488)
ci/woodpecker/pr/ci-scripts-test Pipeline was successful
ci/woodpecker/pr/pr-review Pipeline was successful
Built static in the go stage with go install (module checked against
sum.golang.org); added to the default-PATH check and the README table.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-02 20:58:58 +00:00
argus-bot (Paperclip service account) 3013d04143 Merge pull request 'network-policies: open duty-list targets for agent sandbox pods (REN-487)' (#1100) from atlas/ren-487-agent-pod-egress into master 2026-10-02 20:51:49 +00:00
atlas-botandClaude Opus 5.5 ded86ac6ba network-policies: open duty-list targets for agent sandbox pods (REN-487)
ci/woodpecker/pr/ci-scripts-test Pipeline was successful
ci/woodpecker/pr/ci-manifests-test Pipeline failed
ci/woodpecker/pr/pr-review Pipeline was successful
- apiserver CNP selects paperclip.io/role=agent: the plugin writes the run id
  into paperclip.io/agent-id, so the agent-id selector never matched (REN-428).
- agent pods reach the wiki API (egress here, ingress in ai-ns.yaml).
- FQDN allow for api.github.com, GitHub release-asset hosts, vuln.go.dev,
  uptime.renner.uno.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-02 20:46:02 +00:00
security-bot bf70ef84c7 chore(image-automation): bump ghcr.io/music-assistant/server:2.10.5
ci/woodpecker/cron/issue-fix Pipeline was successful
ci/woodpecker/cron/alert-monitor Pipeline was successful
Updates managed by image-automation-controller.
2026-10-02 12:40:24 +00:00
argus-bot (Paperclip service account) a0151c9a1d Merge pull request 'immich: retire orphaned immich-library PVC from git (REN-453)' (#1099) from atlas/ren-453-retire-immich-library into master
ci/woodpecker/cron/issue-fix Pipeline was successful
ci/woodpecker/cron/e2e Pipeline failed
ci/woodpecker/cron/security-scan Pipeline was successful
ci/woodpecker/cron/alert-monitor Pipeline was successful
2026-10-02 04:16:27 +00:00
atlas-botandClaude Opus 5.5 bff1bec2d6 chore(immich): retire orphaned immich-library PVC from git (REN-453)
ci/woodpecker/pr/ci-scripts-test Pipeline was successful
ci/woodpecker/pr/pr-review Pipeline was successful
ci/woodpecker/pr/ci-manifests-test Pipeline failed
immich-server mounts immich-library-bulk + immich-thumbs since 4cc1b643;
immich-library is mounted by no pod but is still backed up (~250 GiB)
and restored by the restore test. The newest immich-daily backup
(immich-daily-20261001051507) holds immich-library-bulk and immich-thumbs.

Drop the PVC manifest and update comments that cited it. The PVC keeps
prune: disabled, so this merge does not delete the live volume; that is
a separate, owner-approved step.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-01 17:18:03 +00:00
argus-bot (Paperclip service account) 125f8ec7ef Merge pull request 'velero restore-test: abort a restore before it fills Ceph (REN-451)' (#1098) from atlas/ren-451-restore-abort into master
ci/woodpecker/cron/wiki-maintenance Pipeline was successful
ci/woodpecker/cron/issue-fix Pipeline was successful
ci/woodpecker/cron/alert-monitor Pipeline was successful
2026-10-01 17:15:40 +00:00
atlas-botandClaude Opus 5.5 518e72b83f velero restore-test: abort a restore before it fills Ceph (REN-451)
ci/woodpecker/pr/ci-scripts-test Pipeline was successful
ci/woodpecker/pr/ci-manifests-test Pipeline failed
ci/woodpecker/pr/pr-review Pipeline was successful
On 2026-10-01 the immich restore took the fullest OSD from 74% to 95%;
the Job died at its deadline, the Restore kept writing unwatched and
Ceph went OSD_FULL at 15:10.

- Mid-run guard: each restore poll reads the fullest OSD; at 83%
  (OSD_ABORT_PCT, below nearfull) or after 4 polls with no reading,
  cancel the DataDownloads, tear the restore down, stop the sweep (FAIL).
- A restore timeout cancels the same way.
- TERM/EXIT trap cancels the restore in flight; grace period 600 s.
- Time budget: no restore starts whose timeout + 900 s reserve passes
  the Job deadline (SKIP).
- RBAC: get/list/patch on velero.io datadownloads only.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-01 17:08:13 +00:00
argus-bot (Paperclip service account) a6c2ca5c6a Merge pull request 'velero restore-test: never restore, clone or count CNPG volumes (REN-451)' (#1097) from atlas/ren-451-restore-test-skip-cnpg into master
ci/woodpecker/cron/alert-monitor Pipeline was successful
2026-10-01 16:55:09 +00:00
atlas-botandClaude Opus 5.5 835bc3e97a velero restore-test: never restore, clone or count CNPG volumes (REN-451)
ci/woodpecker/pr/ci-scripts-test Pipeline was successful
ci/woodpecker/pr/ci-manifests-test Pipeline failed
ci/woodpecker/pr/pr-review Pipeline was successful
The Restore took every PVC in the backup, and the parity probe then
snapshotted and cloned each restored PVC name in the live namespace. A
backup that holds a CNPG PVC would give two extra copies of the
database, one of them next to production.

- Restore: labelSelector cnpg.io/cluster DoesNotExist.
- Parity loop: only restored PVCs without cnpg.io/cluster.
- Capacity gate: leave CNPG DataUploads out, and add the source-side
  probe clone (size-3 pool) for every PVC the run will probe.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-01 16:53:04 +00:00
k.renner 9ea9cd67c5 Merge pull request 'zigbee2mqtt: apply WS90 reporting config via external converter' (#1092) from z2m-ws90-converter into master
ci/woodpecker/cron/security-scan Pipeline was successful
ci/woodpecker/cron/e2e Pipeline failed
ci/woodpecker/cron/issue-fix Pipeline was successful
ci/woodpecker/cron/alert-monitor Pipeline was successful
Reviewed-on: k.renner/homelab#1092
2026-10-01 10:40:53 +00:00
argus-bot (Paperclip service account) 8ce6922020 Merge pull request 'velero restore-test: skip a restore projected past 80% OSD usage (REN-442)' (#1093) from atlas/ren-442-restore-capacity-gate into master 2026-10-01 10:31:00 +00:00
atlas-botandClaude Opus 5.5 b1d023fc1d velero restore-test: skip a restore projected past 80% OSD usage
ci/woodpecker/pr/ci-scripts-test Pipeline was successful
ci/woodpecker/pr/ci-manifests-test Pipeline failed
ci/woodpecker/pr/pr-review Pipeline was successful
Before each schedule's restore, project its raw size (DataUpload
totalBytes x pool replication/EC factor, spread over all OSDs) onto
current OSD usage from Prometheus. If the fullest OSD would go above
OSD_MAX_PCT (80), skip the schedule and report SKIP with the projected %.
Skips are listed in the summary and do not fail the Job; a projection
that cannot be made fails that schedule without restoring.

Allows the restore-test pod to reach Prometheus :9090 and notes the gate
in RECOVERY.md. No alert rule changes. Refs REN-441, REN-442.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-01 10:25:09 +00:00
claude-botandClaude Opus 5.5 025423b342 zigbee2mqtt: apply WS90 reporting config via external converter
ci/woodpecker/pr/ci-scripts-test Pipeline was successful
ci/woodpecker/pr/pr-review Pipeline was successful
ci/woodpecker/pr/ci-manifests-test Pipeline failed
The WS90 reporting configuration (zigbee2mqtt-ws90-reporting.md) only
lived on the device and in database.db; every interview or
device/configure reset it to the converter defaults (2026-09-24..28,
zero frames recurred).

New external converter extends the built-in WS90 definition with a
configure step that sets the documented values. Its version
(ws90-reporting-1) makes Z2M reconfigure the device once after load.
seed-data copies converters from a ConfigMap into
/app/data/external_converters on every start; not mounted because Z2M
writes a temp copy into that directory while loading.

Tested in the running pod against a mocked device: the definition is
picked over the built-in one, and configure ends with the ten
documented reporting values.

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
2026-10-01 12:01:21 +02:00
k.renner 05dfabb528 Merge pull request 'zigbee2mqtt: raise memory limit to 1Gi' (#1074) from z2m-memory-limit into master
ci/woodpecker/cron/alert-monitor Pipeline was successful
Reviewed-on: k.renner/homelab#1074
2026-10-01 09:53:24 +00:00
argus-bot (Paperclip service account) d3f89b1477 Merge pull request 'monitoring: stop wear alerts on EPHEMERAL NVMe drives (REN-419)' (#1088) from atlas/ren-419-ephemeral-wear-alert into master
ci/woodpecker/cron/issue-fix Pipeline was successful
ci/woodpecker/cron/alert-monitor Pipeline was successful
2026-10-01 09:19:18 +00:00
atlas-botandClaude Opus 5.5 42e67219e0 monitoring: feed disk-wear case A at 5m so the 6h for completes (REN-438)
ci/woodpecker/pr/ci-scripts-test Pipeline was successful
ci/woodpecker/pr/pr-review Pipeline was successful
ci/woodpecker/pr/ci-manifests-test Pipeline was successful
Case A sampled at 1h; with the 5m lookback the series were absent for most
of each hour and the pending alert reset, so the projection never fired.
Now 5m samples (1m exceeds promtool's sample limit on the 7d rate), same
0.04272 %/day and 140-day summary.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-01 09:07:58 +00:00
argus-bot (Paperclip service account) 6bf9541625 Merge pull request 'docs(monitoring): record the ESO scrape trust boundary and real grant scope (REN-100)' (#998) from atlas/ren-103-scrape-doc-gaps into master
ci/woodpecker/cron/alert-monitor Pipeline was successful
2026-10-01 09:03:17 +00:00
atlas-botandClaude Opus 5.5 18629fd496 monitoring: stop wear alerts on EPHEMERAL NVMe drives (REN-419)
ci/woodpecker/pr/ci-scripts-test Pipeline was successful
ci/woodpecker/pr/ci-manifests-test Pipeline failed
ci/woodpecker/pr/pr-review Pipeline was successful
The owner decided EPHEMERAL (/var) drives run to failure (REN-420), so
NvmeDriveWearProjectedExhaustion and NvmeDriveWearCritical now skip the
drive carrying /var. The drive is resolved live by joining node-exporter's
/var mount onto smartctl-exporter's (node, device) through a recording rule;
if the join stops matching, the alerts return rather than go quiet. Spare,
critical-warning and media-error alerts still cover EPHEMERAL drives.

Adds a promtool suite and four negative controls for the exclusion.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-01 05:40:32 +00:00
argus-bot (Paperclip service account) 7ae8276dea Merge pull request 'paperclip: per-agent kubectl ServiceAccounts + apiserver egress CNP (REN-414)' (#1080) from atlas/ren-414-agent-kubectl-sa into master
ci/woodpecker/cron/wiki-maintenance Pipeline was successful
ci/woodpecker/cron/issue-fix Pipeline was successful
ci/woodpecker/cron/alert-monitor Pipeline was successful
2026-09-30 23:19:33 +00:00
atlas-botandClaude Opus 5.5 0d1181abb1 paperclip: per-agent kubectl ServiceAccounts + apiserver egress CNP (REN-414)
ci/woodpecker/pr/ci-manifests-test Pipeline was successful
ci/woodpecker/pr/ci-scripts-test Pipeline was successful
ci/woodpecker/pr/pr-review Pipeline was successful
Five ServiceAccounts agent-{atlas,iris,hestia,argus,hermes} in paperclip
with empty service-account-token Secrets. The four readers get the same
rights they hold today via the shared pod SA: `view` cluster-wide and the
existing monitoring/paperclip-prometheus-read Role. Hermes and the shared
SA get `get` on the five named token Secrets only.

CiliumNetworkPolicy paperclip-renner/paperclip-agents-kube-apiserver lets
the five agents' pods reach the kube-apiserver entity on 6443.

Spec: REN-412. Nothing restarts.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-09-30 23:14:52 +00:00
argus-bot (Paperclip service account) cf77302899 Merge pull request 'network-policies: agent pods in paperclip-renner reach Gitea via Traefik (REN-411)' (#1079) from atlas/ren-411-agent-gitea-egress into master
ci/woodpecker/cron/alert-monitor Pipeline was successful
2026-09-30 22:58:00 +00:00
atlas-botandClaude Opus 5.5 e8ba85ca76 network-policies: let paperclip-renner agent pods reach Traefik on 8443 (REN-411)
ci/woodpecker/pr/ci-scripts-test Pipeline was successful
ci/woodpecker/pr/ci-manifests-test Pipeline was successful
ci/woodpecker/pr/pr-review Pipeline was successful
gitea.renner.uno resolves to the Traefik LB VIP; Cilium DNATs it to a Traefik
pod before egress policy, so the plugin's toFQDNs allow never matches.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-09-30 22:56:03 +00:00
security-bot 3fffd5a4ef chore(image-automation): bump gitea.renner.uno/konairius/paperclip:build.1790806287@sha256:f0b4b4e09cc02fbc472faedf3edb6d39339ade7e2932c6a435f601209b92d646
ci/woodpecker/cron/issue-fix Pipeline was successful
ci/woodpecker/cron/alert-monitor Pipeline was successful
Updates managed by image-automation-controller.
2026-09-30 22:35:10 +00:00
argus-bot (Paperclip service account) 5062b09214 Merge pull request 'paperclip: apply upstream PR #14769 to the image (REN-409)' (#1078) from atlas/ren-409-paperclip-14769 into master
ci/woodpecker/push/build-ci-images Pipeline was successful
ci/woodpecker/push/build-paperclip Pipeline was successful
ci/woodpecker/cron/alert-monitor Pipeline was successful
2026-09-30 22:10:51 +00:00
atlas-botandClaude Opus 5.5 c165f3d687 paperclip: apply upstream PR #14769 to the image (REN-409)
ci/woodpecker/pr/ci-scripts-test Pipeline was successful
ci/woodpecker/pr/pr-review Pipeline was successful
Adapter environment tests sync managed config into the pod before any
workspace is realized, so the lease has no remoteCwd and the Claude test
fails with claude_managed_config_dir_failed. #13733 fixes only the run
path. #14769 (open upstream, head 10dc7371) makes the Kubernetes plugin
set remoteCwd=/workspace on acquire and keep a recorded one on resume.
The plugin build from REN-405 is unchanged, so dist/ carries the fix.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-09-30 22:09:04 +00:00
security-bot d30c2aa498 chore(image-automation): bump gitea.renner.uno/konairius/paperclip:build.1790803664@sha256:e04780cf178e99195da4a6796b0f97d718ca27c332769350e1bfc875c722e75d
ci/woodpecker/cron/alert-monitor Pipeline was successful
Updates managed by image-automation-controller.
2026-09-30 21:45:10 +00:00
argus-bot (Paperclip service account) 571a87746a Merge pull request 'paperclip: build the Kubernetes sandbox plugin into the image (REN-405)' (#1077) from atlas/ren-405-k8s-plugin-dist into master
ci/woodpecker/push/build-ci-images Pipeline was successful
ci/woodpecker/cron/issue-fix Pipeline was successful
ci/woodpecker/push/build-paperclip Pipeline was successful
ci/woodpecker/cron/alert-monitor Pipeline was successful
2026-09-30 21:27:19 +00:00
atlas-botandClaude Opus 5.5 8aa432c6ec paperclip: build the Kubernetes sandbox plugin into the image (REN-405)
ci/woodpecker/pr/ci-scripts-test Pipeline was successful
ci/woodpecker/pr/pr-review Pipeline was successful
Upstream's production target ships the plugin source without dist/, so the
plugin loader reports paperclip.kubernetes-sandbox-provider as "no longer
exposes a Paperclip manifest". prepare.sh now adds upstream's cloud-plugins
commands for kubernetes to the build stage, after the server build, and fails
the build if dist/manifest.js is missing. The #13733 patch is unchanged.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-09-30 21:23:40 +00:00
security-bot f6981ffdbe chore(image-automation): bump gitea.renner.uno/konairius/paperclip:build.1790800098@sha256:381fac2f844114a87a537095705318524f22a8cbfa31558c66fdd49527c0e9bd
ci/woodpecker/cron/alert-monitor Pipeline was successful
Updates managed by image-automation-controller.
2026-09-30 20:45:09 +00:00
argus-bot (Paperclip service account) e2ad903f02 Merge pull request 'paperclip build: kaniko --compressed-caching=false after OOM kill (REN-401)' (#1076) from atlas/ren-401-kaniko-oom into master
ci/woodpecker/cron/issue-fix Pipeline was successful
ci/woodpecker/push/build-paperclip Pipeline was successful
ci/woodpecker/cron/alert-monitor Pipeline was successful
2026-09-30 20:27:55 +00:00
atlas-botandClaude Opus 5.5 aed1ab5d75 paperclip build: kaniko --compressed-caching=false after OOM kill (REN-401)
ci/woodpecker/pr/ci-scripts-test Pipeline was successful
ci/woodpecker/pr/ci-manifests-test Pipeline was successful
ci/woodpecker/pr/pr-review Pipeline was successful
Pipeline 11717 build-paperclip exited 137 at the 8Gi memory limit during
the server build. Disable compressed caching so kaniko does not keep
compressed layer tarballs in memory.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-09-30 20:25:11 +00:00
argus-bot (Paperclip service account) 01451a7eb3 Merge pull request 'paperclip: build upstream a027f76 + PR #13733, track it with Flux (REN-401)' (#1075) from atlas/ren-401-paperclip-patched-image into master
ci/woodpecker/push/build-ci-images Pipeline was successful
ci/woodpecker/cron/alert-monitor Pipeline was successful
ci/woodpecker/push/build-paperclip Pipeline failed
2026-09-30 20:03:55 +00:00
atlas-botandClaude Opus 5.5 864d104d0c paperclip: build upstream a027f76 + PR #13733 and track it (REN-401)
ci/woodpecker/pr/ci-scripts-test Pipeline was successful
ci/woodpecker/pr/ci-manifests-test Pipeline was successful
ci/woodpecker/pr/pr-review Pipeline was successful
k8s sandbox runs fail because the run path never sets the lease remoteCwd
(paperclipai/paperclip#13864). The fix, paperclipai/paperclip#13733, is not
merged upstream yet. Build our own image from the master commit the nightly
runs now plus that patch, and point Flux image automation at it.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-09-30 19:59:22 +00:00
security-bot 07dc3ebea1 chore(image-automation): bump ghcr.io/usetrmnl/terminus:0.76.0
ci/woodpecker/cron/issue-fix Pipeline was successful
ci/woodpecker/cron/alert-monitor Pipeline was successful
Updates managed by image-automation-controller.
2026-09-30 18:40:44 +00:00
security-bot 96cfe20249 chore(image-automation): bump ghcr.io/cloudnative-pg/plugin-barman-cloud-sidecar:v0.15.1
ci/woodpecker/cron/issue-fix Pipeline was successful
ci/woodpecker/cron/alert-monitor Pipeline was successful
Updates managed by image-automation-controller.
2026-09-30 14:40:41 +00:00
security-bot ba099fccbe chore(image-automation): bump ghcr.io/cloudnative-pg/plugin-barman-cloud:v0.15.1
Updates managed by image-automation-controller.
2026-09-30 14:40:03 +00:00
security-bot feef462935 chore(image-automation): bump ghcr.io/paperclipai/paperclip:nightly@sha256:c035c731e082533ae3a5a67ddafbe7636619a6148de6bce36c67cc842ac84ea2
ci/woodpecker/cron/e2e Pipeline failed
ci/woodpecker/cron/security-scan Pipeline was successful
ci/woodpecker/cron/issue-fix Pipeline was successful
ci/woodpecker/cron/alert-monitor Pipeline was successful
Updates managed by image-automation-controller.
2026-09-30 10:27:01 +00:00
claude-botandClaude Opus 5.5 3e1599bcad zigbee2mqtt: raise memory limit to 1Gi
ci/woodpecker/pr/ci-scripts-test Pipeline was successful
ci/woodpecker/pr/ci-manifests-test Pipeline was successful
ci/woodpecker/pr/pr-review Pipeline was successful
Node derives the V8 heap from the container limit: 512Mi gave a
259 MB heap, and Z2M crashed with "JavaScript heap out of memory"
(exit 134) at 2026-09-28 17:56Z and 2026-09-29 07:36Z. Request
raised to 256Mi to cover the measured 232Mi working set.

Co-Authored-By: Claude Opus 5.5 (1M context) <noreply@anthropic.com>
2026-09-30 07:30:17 +02:00
argus-bot (Paperclip service account) 92ba011aca Merge pull request 'navidrome: beets writes the retried partial-album matches (REN-350)' (#1073) from atlas/ren-350-beets-write-retry into master
ci/woodpecker/cron/issue-fix Pipeline was successful
ci/woodpecker/cron/alert-monitor Pipeline was successful
2026-09-30 03:04:40 +00:00
atlas-botandClaude Opus 5.5 d95a5e9137 navidrome: beets writes the retried partial-album matches, drops one wrong match (REN-350)
ci/woodpecker/pr/ci-manifests-test Pipeline was successful
ci/woodpecker/pr/ci-scripts-test Pipeline was successful
ci/woodpecker/pr/pr-review Pipeline was successful
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-09-30 03:02:24 +00:00
argus-bot (Paperclip service account) 635bd6a02c Merge pull request 'chore(home-assistant): drop unused backup-password ExternalSecret, fix stale seed comment (REN-339)' (#1062) from atlas/ren-339-ha-backup-cleanup into master
ci/woodpecker/cron/issue-fix Pipeline was successful
ci/woodpecker/cron/alert-monitor Pipeline was successful
ci/woodpecker/cron/wiki-maintenance Pipeline was successful
2026-09-30 00:06:06 +00:00
security-bot 507c807925 chore(image-automation): bump ghcr.io/advplyr/audiobookshelf:2.37.1
ci/woodpecker/cron/issue-fix Pipeline was successful
ci/woodpecker/cron/alert-monitor Pipeline was successful
Updates managed by image-automation-controller.
2026-09-29 23:40:31 +00:00
k.renner 37f2bd0718 Merge pull request 'fix(navidrome): let non-browser clients reach the native API' (#1072) from fix/navidrome-native-api into master
ci/woodpecker/cron/issue-fix Pipeline was successful
ci/woodpecker/cron/alert-monitor Pipeline was successful
Reviewed-on: k.renner/homelab#1072
2026-09-29 13:42:16 +00:00
claude-botandClaude Opus 5.5 1184a552fb fix(navidrome): let non-browser clients reach the native API
ci/woodpecker/pr/ci-scripts-test Pipeline was successful
ci/woodpecker/pr/pr-review Pipeline was successful
ci/woodpecker/pr/ci-manifests-test Pipeline was successful
Koda (Garmin Connect IQ) calls POST /auth/login during sync. Only /rest
and /share bypassed the navidrome-gate, so the gate answered 302 with an
empty body and the watch failed with -400
INVALID_HTTP_BODY_IN_NETWORK_RESPONSE ("Native login failed -400").

An IngressRoute sends /auth and /api straight to Navidrome when the
request carries no authentik_proxy_ session cookie; requests with the
cookie (the web UI) keep going through the gate, so SSO is unchanged.
X-Authentik-Username is stripped on this route as on /rest.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-09-29 15:41:36 +02:00
security-bot f53d41d3c9 chore(image-automation): bump ghcr.io/paperclipai/paperclip:nightly@sha256:c02c7a8385fe5e3e9999ec03ecb45f29d60b8bf44dac3fedf032d7ef2046045d
ci/woodpecker/cron/e2e Pipeline failed
ci/woodpecker/cron/security-scan Pipeline was successful
ci/woodpecker/cron/alert-monitor Pipeline was successful
ci/woodpecker/cron/issue-fix Pipeline was successful
Updates managed by image-automation-controller.
2026-09-29 10:26:36 +00:00
argus-bot (Paperclip service account) 569f8e0b4c Merge pull request 'network-policies: paperclip agents may reach the Lidarr API on 8686 (REN-350)' (#1071) from atlas/ren-350-paperclip-lidarr-cnp into master 2026-09-29 10:25:08 +00:00
atlas-botandClaude Opus 5.5 9b72377b9c network-policies: let paperclip agents reach the Lidarr API on 8686 (REN-350)
ci/woodpecker/pr/ci-scripts-test Pipeline was successful
ci/woodpecker/pr/ci-manifests-test Pipeline was successful
ci/woodpecker/pr/pr-review Pipeline was successful
Owner-approved on REN-350. Only the Lidarr pod, only 8686; nothing else in
navidrome is admitted. Lidarr uses AUTH__METHOD External, so this gives
agents in the paperclip pod full Lidarr access.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-09-29 10:22:48 +00:00
argus-bot (Paperclip service account) 0ed9565553 Merge pull request 'navidrome: beets retries skipped albums (partial-album match trial, no writes) (REN-350)' (#1070) from atlas/ren-350-beets-retry-skips into master
ci/woodpecker/cron/alert-monitor Pipeline was successful
2026-09-29 10:04:01 +00:00
atlas-botandClaude Opus 5.5 bd300ffcfa navidrome: beets trial lists re-matched albums whose release changed (REN-350)
ci/woodpecker/pr/ci-scripts-test Pipeline was successful
ci/woodpecker/pr/ci-manifests-test Pipeline was successful
ci/woodpecker/pr/pr-review Pipeline was successful
Review 1258: the 74 written albums are re-imported, not duplicate-skipped.
Fix the comment and report before/after mb_albumid per album.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-09-29 10:03:07 +00:00
atlas-botandClaude Opus 5.5 bb69b196e4 navidrome: beets retries skipped albums, partial-album match trial with -W (REN-350)
ci/woodpecker/pr/ci-scripts-test Pipeline was successful
ci/woodpecker/pr/ci-manifests-test Pipeline was successful
ci/woodpecker/pr/pr-review Pipeline was successful
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-09-29 10:00:32 +00:00
argus-bot (Paperclip service account) 9ab8bc9735 Merge pull request 'navidrome: beets writes tags (write: yes) (REN-350)' (#1069) from atlas/ren-350-beets-write into master
ci/woodpecker/cron/issue-fix Pipeline was successful
ci/woodpecker/cron/alert-monitor Pipeline was successful
2026-09-29 07:21:32 +00:00
atlas-botandClaude Opus 5.5 af0c0829af navidrome: beets writes tags (write: yes, beet write) (REN-350)
ci/woodpecker/pr/ci-scripts-test Pipeline was successful
ci/woodpecker/pr/ci-manifests-test Pipeline was successful
ci/woodpecker/pr/pr-review Pipeline was successful
Two dry runs were checked; the spot check now matches original releases.
Music mount becomes writable for tag writes; move/copy/delete stay off.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-09-29 07:17:34 +00:00
argus-bot (Paperclip service account) b670c94bf0 Merge pull request 'chore(ci): bump ci-claude image to 2.1.283' (#1057) from ci-image/claude-2.1.283 into master
ci/woodpecker/cron/issue-fix Pipeline was successful
ci/woodpecker/cron/alert-monitor Pipeline was successful
2026-09-29 05:17:01 +00:00
argus-bot (Paperclip service account) f91f2dc08b Merge pull request 'navidrome: beets prefers original releases, reset dry-run DB once (REN-350)' (#1068) from atlas/ren-350-beets-phase2 into master
ci/woodpecker/cron/issue-fix Pipeline was successful
ci/woodpecker/cron/alert-monitor Pipeline was successful
2026-09-29 04:22:18 +00:00
atlas-botandClaude Opus 5.5 283415e689 navidrome: beets prefers original releases, reset dry-run DB once (REN-350)
ci/woodpecker/pr/ci-scripts-test Pipeline was successful
ci/woodpecker/pr/ci-manifests-test Pipeline was successful
ci/woodpecker/pr/pr-review Pipeline was successful
The first dry run (write: no) matched 78 of 560 albums; some matched
reissues (JP/RU) and would have changed year to the reissue year.
Set original_date and preferred countries/media/original_year, and
drop the dry-run beets DB once so the next run re-matches. Still write: no.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-09-29 04:21:16 +00:00
security-bot 0bf8c43970 chore(image-automation): bump ghcr.io/advplyr/audiobookshelf:2.37.0
ci/woodpecker/cron/wiki-maintenance Pipeline was successful
ci/woodpecker/cron/issue-fix Pipeline was successful
ci/woodpecker/cron/alert-monitor Pipeline was successful
Updates managed by image-automation-controller.
2026-09-28 23:40:15 +00:00
security-bot 1cced943c1 chore(image-automation): bump ghcr.io/usetrmnl/trmnl-ha-amd64:0.11.0
ci/woodpecker/cron/issue-fix Pipeline was successful
ci/woodpecker/cron/alert-monitor Pipeline was successful
Updates managed by image-automation-controller.
2026-09-28 20:40:13 +00:00
argus-bot (Paperclip service account) 81418f5b36 Merge pull request 'navidrome: add beets CronJob, tags to DB only (REN-350)' (#1067) from atlas/ren-350-beets-cronjob into master
ci/woodpecker/cron/issue-fix Pipeline was successful
ci/woodpecker/cron/alert-monitor Pipeline was successful
2026-09-28 18:35:11 +00:00
atlas-botandClaude Opus 5.5 425fe260e9 navidrome/beets: mount music library read-only (review 1248)
ci/woodpecker/pr/ci-scripts-test Pipeline was successful
ci/woodpecker/pr/ci-manifests-test Pipeline was successful
ci/woodpecker/pr/pr-review Pipeline was successful
Phase 1 runs with write: no; beets writes only to /config.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-09-28 18:31:51 +00:00
atlas-botandClaude Opus 5.5 7a1f9de069 navidrome: add beets CronJob, tags to DB only (REN-350)
ci/woodpecker/pr/ci-scripts-test Pipeline was successful
ci/woodpecker/pr/ci-manifests-test Pipeline was successful
ci/woodpecker/pr/pr-review Pipeline was successful
Nightly beets import over navidrome-music-bulk, in place: no move, copy,
rename or delete. First phase is write: no with fetchart/embedart off;
the job log prints matched/skipped counts and a beet write -p preview.
Renovate rule for the LinuxServer -ls<n> tag.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-09-28 18:29:08 +00:00
security-bot 7294a610a4 chore(image-automation): bump ghcr.io/immich-app/immich-server:v3.2.4
ci/woodpecker/cron/alert-monitor Pipeline was successful
Updates managed by image-automation-controller.
2026-09-28 17:49:10 +00:00
security-bot 9136f01156 chore(image-automation): bump ghcr.io/immich-app/immich-machine-learning:v3.2.4
ci/woodpecker/cron/alert-monitor Pipeline was successful
Updates managed by image-automation-controller.
2026-09-28 17:42:06 +00:00
argus-bot (Paperclip service account) 45c252c15e Merge pull request 'chore(ha-restore-test): tear down the HA backup restore test (REN-339)' (#1066) from atlas/ren-339-restore-test-teardown into master
ci/woodpecker/cron/issue-fix Pipeline was successful
2026-09-28 17:36:04 +00:00
atlas-botandClaude Opus 5.5 788896902b chore(ha-restore-test): tear down the HA backup restore test (REN-339)
ci/woodpecker/pr/ci-scripts-test Pipeline was successful
ci/woodpecker/pr/ci-manifests-test Pipeline was successful
ci/woodpecker/pr/pr-review Pipeline was successful
C.1 (CNPG ha-pg) and C.2 (Velero /config) passed; results are on REN-339.
Removing the Flux Kustomization lets prune delete namespace ha-restore-test
with the recovered cluster, the Jobs, the Velero Restore and the restored PVC.
Also drops ha-restore-test from the OpenBao ClusterSecretStore allowlist.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-09-28 17:34:34 +00:00
argus-bot (Paperclip service account) 347b7e0806 Merge pull request 'fix(ha-restore-test): recreate recovered cluster as ha-pg-restore-2 (REN-339)' (#1065) from atlas/ren-339-restore-roll into master
ci/woodpecker/cron/alert-monitor Pipeline was successful
2026-09-28 17:26:25 +00:00
atlas-botandClaude Opus 5.5 b86ee49c98 fix(ha-restore-test): recreate recovered cluster as ha-pg-restore-2 so it starts with the plugin sidecar (REN-339)
ci/woodpecker/pr/ci-scripts-test Pipeline was successful
ci/woodpecker/pr/ci-manifests-test Pipeline was successful
ci/woodpecker/pr/pr-review Pipeline was successful
The operator will not roll ha-pg-restore-1 after #1063; it waits on an
in-place restart the stopped instance manager cannot answer. A new name
makes Flux prune the old Cluster (pod + ephemeral PVC) and create a fresh
one. The check Job is renamed too (Job templates are immutable).

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-09-28 17:25:20 +00:00
argus-bot (Paperclip service account) 14b248b1a4 Merge pull request 'fix(ha-restore-test): load barman-cloud plugin without WAL archiver so restored PG starts (REN-339)' (#1063) from atlas/ren-339-restore-plugin into master
ci/woodpecker/cron/alert-monitor Pipeline was successful
2026-09-28 17:04:07 +00:00
atlas-botandClaude Opus 5.5 e2705ba0fb fix(ha-restore-test): load barman-cloud plugin (no WAL archiver) so the restored instance starts (REN-339)
ci/woodpecker/pr/ci-scripts-test Pipeline was successful
ci/woodpecker/pr/ci-manifests-test Pipeline was successful
ci/woodpecker/pr/pr-review Pipeline was successful
The instance manager refuses to start PostgreSQL when the Cluster references
a plugin (externalClusters) that has no sidecar in the pod. Add a plugins
entry with isWALArchiver: false and a distinct serverName.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-09-28 17:02:38 +00:00
argus-bot (Paperclip service account) 8f9d57aade Merge pull request 'feat(ha-restore-test): throwaway HA backup restore test outside production (REN-339)' (#1061) from atlas/ren-339-ha-restore-test into master
ci/woodpecker/cron/alert-monitor Pipeline was successful
2026-09-28 16:41:31 +00:00
atlas-botandClaude Opus 5.5 4c4f69c4ec chore(home-assistant): drop unused backup-password ExternalSecret, fix stale seed comment (REN-339)
ci/woodpecker/pr/ci-manifests-test Pipeline was successful
ci/woodpecker/pr/ci-scripts-test Pipeline was successful
ci/woodpecker/pr/pr-review Pipeline was successful
The seed initContainer was removed in 21a0a43f; Velero home-assistant-daily is
now the only /config restore path. home-assistant-backup-password has had no
consumer since then.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-09-28 16:38:25 +00:00
atlas-botandClaude Opus 5.5 5a4f7efd5c feat(ha-restore-test): throwaway HA backup restore test outside production (REN-339)
ci/woodpecker/pr/ci-scripts-test Pipeline was successful
ci/woodpecker/pr/ci-manifests-test Pipeline was successful
ci/woodpecker/pr/pr-review Pipeline was successful
Recovers ha-pg from Barman into ha-pg-restore (no WAL archiver) and restores
the home-assistant-daily Velero backup into namespace ha-restore-test. Two
Jobs log the runbook C.1/C.2 checks. The /config probe is deny-all and never
runs Home Assistant. Nothing in namespace home-assistant changes.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-09-28 16:37:43 +00:00
security-bot 36f54b61b6 chore(image-automation): bump ghcr.io/paperclipai/paperclip:nightly@sha256:50f66b31fa08fe5dee20d9130e4882852c6f1a8f29eda40bfb6ce026202b2da3
ci/woodpecker/cron/e2e Pipeline failed
ci/woodpecker/cron/security-scan Pipeline was successful
ci/woodpecker/cron/alert-monitor Pipeline was successful
ci/woodpecker/cron/issue-fix Pipeline was successful
Updates managed by image-automation-controller.
2026-09-28 10:26:14 +00:00
argus-bot (Paperclip service account) bab09d5f6c Merge pull request 'fix(renovate): let containerbase install tools, run with group 0 (REN-315)' (#1059) from atlas/ren-315-renovate-tool-install into master
ci/woodpecker/cron/issue-fix Pipeline was successful
ci/woodpecker/cron/alert-monitor Pipeline was successful
2026-09-28 05:30:30 +00:00
argus-bot (Paperclip service account) 3302f6c6b6 Merge pull request 'fix(renovate): no digest pins for our images; split the weekly group (REN-315)' (#1058) from atlas/ren-315-renovate-groups into master 2026-09-28 05:30:25 +00:00
atlas-botandClaude Opus 5.5 836dbb3f92 fix(renovate): no digest pins for our images; split the weekly group (REN-315)
ci/woodpecker/pr/ci-scripts-test Pipeline was successful
ci/woodpecker/pr/pr-review Pipeline was successful
- gitea.renner.uno/**: pinDigests false. Our images are pinned by dated
  tag; registry GC deletes their digests (no-digest-pins, homelab #1053).
- The weekly non-major group becomes: one PR each for gitea, authentik,
  influxdb, openbao and multus/CNI (migrations or CNI, a revert does not
  undo them); one for kubernetes/apps/home-assistant/** (HA-impact review,
  02:00-05:00 window); one CI-only for .woodpecker/** and ci/images/**.
  Everything else stays in "all non-major dependencies".
- openbao chart: rangeStrategy bump. The default rewrote the bounded range
  ">=0.28.4 <0.29.0" to "<0.30.0" (homelab #1054) and dropped the lower
  bound; bump gives ">=0.29.6 <0.30.0".

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-09-28 05:20:10 +00:00
atlas-botandClaude Opus 5.5 b0aa6dee15 fix(renovate): let containerbase install tools, run with group 0 (REN-315)
ci/woodpecker/pr/ci-manifests-test Pipeline was successful
ci/woodpecker/pr/ci-scripts-test Pipeline was successful
ci/woodpecker/pr/pr-review Pipeline was successful
The slim Renovate image installs tools (golang for go.sum, helm) at run
time into /opt/containerbase, which it ships as root:root 0775 for its
user ubuntu (uid 12021, gid 0). The job ran with gid 12021 and a
read-only root, so every install failed ("Install tool golang failed",
ical-proxy #12) and go.sum was never updated.

Run with gid 0 and a writable root file system. The user stays
non-root, capabilities stay dropped, no API token is mounted.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-09-28 05:07:31 +00:00
claude-bot 541094b41d chore(ci): bump ci-claude image to 2.1.283
ci/woodpecker/pr/ci-manifests-test Pipeline was successful
ci/woodpecker/pr/ci-scripts-test Pipeline was successful
ci/woodpecker/pr/pr-review Pipeline was successful
2026-09-28 05:04:57 +00:00
argus-bot (Paperclip service account) 8b4661fb45 Merge pull request 'chore(deps): update node.js to v24' (#1055) from renovate/node-24.x into master
ci/woodpecker/push/build-ci-images Pipeline was successful
ci/woodpecker/push/ci-claude-refresh Pipeline was successful
ci/woodpecker/cron/alert-monitor Pipeline was successful
2026-09-28 05:03:22 +00:00
renovate-bot 518d6768c4 chore(deps): update node.js to v24
ci/woodpecker/pr/ci-scripts-test Pipeline was successful
ci/woodpecker/pr/pr-review Pipeline was successful
2026-09-28 02:01:45 +00:00
argus-bot (Paperclip service account) 352cc1a13f Merge pull request 'fix(monitoring): Prometheus retention 30d/40GiB + alert when retention is not in force (REN-107)' (#1001) from atlas/ren-107-retention-divergence-alert into master
ci/woodpecker/cron/wiki-maintenance Pipeline failed
ci/woodpecker/cron/issue-fix Pipeline was successful
ci/woodpecker/cron/e2e Pipeline failed
ci/woodpecker/cron/alert-monitor Pipeline was successful
ci/woodpecker/cron/update-audit Pipeline was successful
2026-09-28 00:24:46 +00:00
atlas-botandClaude Opus 5.5 cf4da18e83 fix(monitoring): Prometheus retention 30d/40GiB, alert against cap in force, promtool suite (REN-107)
ci/woodpecker/pr/ci-scripts-test Pipeline was successful
ci/woodpecker/pr/ci-manifests-test Pipeline was successful
ci/woodpecker/pr/pr-review Pipeline was successful
Owner decision on REN-107: option B, 30 days on the existing disk.
retention 90d -> 30d, retentionSize 30GB -> 40GiB, PVC unchanged (50Gi).
At ~1 GB/day the 30GiB cap bound first and the real window was a
20.5-27.2 day saw-tooth; 30d peaks near 38 GB, under the 40GiB backstop.

PrometheusRetentionNotInForce now divides the 7d store peak by the cap in
force NOW, not the cap at the time of the peak, so it clears on the day
the fix lands instead of firing for up to 7 days on the old cap's peak.

Adds tests/prometheus-retention_test.yaml (5 scenarios) and 5
`retention-*` mutations, all caught.

Restarts Prometheus once (StatefulSet args change): merge 02:00-05:00
Europe/Berlin.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-09-28 00:21:20 +00:00
3fabf60910 feat(monitoring): alert when Prometheus retention is configured but not in force (REN-107)
`retention: 90d` and `retentionSize: 30GB` are both set on kube-prometheus-stack.
Prometheus honours whichever binds first, and here it is the size cap — so the
time setting is decoration. Measured on the live TSDB through the read-only
proxy grant, 2026-09-26:

    storage.tsdb.retention.size = 30GiB  -> 32,212,254,720 bytes
    storage.tsdb.retention.time = 90d    -> 7,776,000 s
    window actually held                 -> 2,291,239 s (26.5 days, 29% of 90d)

Size eviction is not pending — it has been running on a ~7-day cycle for at
least as long as the TSDB keeps history. At 2026-09-19 23:00->23:30 the store
went 28.16 GB -> 21.14 GB, `prometheus_tsdb_size_retentions_total` went 0 -> 1,
and the window held collapsed 27.21 -> 20.48 days. Effective retention is a
20.5-27.2 day saw-tooth. Nothing reported any of it: none of the 182 alert
rules already loaded touch retention.

REN-107 was filed on a reading of `prometheus_tsdb_size_retentions_total == 0`,
concluding the cap was ~3 days away from binding. That counter is per-process
and resets on restart; this Prometheus has had seven distinct pod IPs in 26
days, and the reading was taken on a pod started 5 days earlier. So this rule
does not read it — it compares the window on disk against the limits the
running process reports, which are true regardless of process age.

No hardcoded 90d or 30GB: both sides come from
`prometheus_tsdb_retention_limit_seconds` / `_bytes`, so editing the HelmRelease
cannot leave this rule stale.

Two clauses. The window is <90% of configured time retention, AND the store
reached 80% of the size cap within the last 7 days. The second is a guard, not
decoration: clause 1 alone fires on a legitimately young TSDB on a fresh PVC.
`max_over_time(...[7d:1h])` spans a full saw-tooth so the alert does not resolve
and re-fire twice a week on an unchanging condition, and the expression is fully
aggregated so that lookback survives the pod restarts above.

Verified against the live TSDB, not just linted — the expression as js-yaml
parses it out of this manifest returns one series with $value 2,291,414 s
(26.52 days). Counterfactuals also run live: it goes silent for a 100GiB cap
(90d intent), for `retention: 21d`, for 30d+40GiB, and for a short window on a
store far from its cap (the fresh-PVC false positive the guard exists to stop).

Scope is the alert only. This does NOT change `retention`, `retentionSize` or
the PVC — which number is the real intent is an owner call on storage cost vs
history, and changing either restarts Prometheus and gaps every series. That
decision is on REN-107 for Zeus; the config change is a separate PR.

Blast radius: a PrometheusRule is additive and loaded by the operator's config
reloader. No workload restarts, no Prometheus restart, no scrape or ingest
change, no existing rule touched, no ingress or DNS change. Worst case is a
malformed rule, which surfaces as PrometheusRuleFailures — already alerted —
and affects only this rule's evaluation.

The alert fires immediately on merge, because the condition is true today. It
clears within one evaluation once the retention config is made honest.

Revert: revert this one commit. The rule is deleted and nothing else changes.

Co-Authored-By: Paperclip <noreply@paperclip.ing>
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-09-28 00:21:08 +00:00
argus-bot (Paperclip service account) b69c7f8985 Merge pull request 'chore(monitoring-rules): remove temporary REN-28 negative-test probes (REN-159)' (#1052) from atlas/ren-159-remove-ren28-negative-probes into master
ci/woodpecker/cron/alert-monitor Pipeline was successful
2026-09-28 00:13:08 +00:00
atlas-botandClaude Opus 5.5 725d4a5204 chore(monitoring-rules): remove temporary REN-28 negative-test probes (REN-159)
ci/woodpecker/pr/ci-scripts-test Pipeline was successful
ci/woodpecker/pr/ci-manifests-test Pipeline was successful
ci/woodpecker/pr/pr-review Pipeline was successful
The blackbox-ren28-negative Probe existed only to take the REN-140 §7
before/after pair across REN-28 PR 2b (#1044). The "after" reading was
taken at merge (27b505e6, 2026-09-28 00:09-00:11Z): all four targets
probe_success 0 at probe_duration_seconds ~5 s, collateral still 1.

Delete the Probe, its kustomization entry, and the now-dangling mention
of the job in the CNPNegativeControlReachable comment. gotenberg:3000
stays covered by the permanent blackbox-negative-control job.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-09-28 00:11:57 +00:00
argus-bot (Paperclip service account) 27b505e6ba Merge pull request 'feat(network-policies): scope paperless database/monitoring ingress per workload (REN-28 PR 2b)' (#1044) from atlas/ren-148-paperless-ingress-scoping into master 2026-09-28 00:06:19 +00:00
argus-bot (Paperclip service account) 2a34573823 Merge pull request 'feat(ci): claude-agent-acp in the agent-runtime images (REN-302)' (#1051) from atlas/ren-302-claude-agent-acp into master
ci/woodpecker/push/build-agent-runtime Pipeline was successful
ci/woodpecker/push/build-ci-images Pipeline was successful
ci/woodpecker/cron/issue-fix Pipeline was successful
ci/woodpecker/cron/alert-monitor Pipeline was successful
2026-09-27 21:41:31 +00:00
atlas-botandClaude Opus 5.5 ed6903ae88 fix(ci): claude-agent-acp with Paperclip's SDK override (REN-302)
ci/woodpecker/pr/ci-scripts-test Pipeline was successful
ci/woodpecker/pr/ci-manifests-test Pipeline was successful
ci/woodpecker/pr/pr-review Pipeline was successful
npm install -g ignored Paperclip's pnpm override and pulled
claude-agent-sdk 0.3.257. Install from a package.json with the override
(0.3.280) into /opt/claude-agent-acp and link the bin into /usr/local/bin.
The build fails if the SDK version is not 0.3.280.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-09-27 21:40:25 +00:00
atlas-botandClaude Opus 5.5 9049a6b241 feat(ci): claude-agent-acp in the agent-runtime images (REN-302)
ci/woodpecker/pr/ci-scripts-test Pipeline was successful
ci/woodpecker/pr/ci-manifests-test Pipeline was successful
ci/woodpecker/pr/pr-review Pipeline was canceled
The k8s-go adapter test failed with 'Claude ACP server command is not
available: claude-agent-acp'. Both agent-runtime images now install
@agentclientprotocol/claude-agent-acp@0.73.0, the version Paperclip pins,
with Paperclip's patch for it applied (vendored in agent-runtime-common/).

go and gofmt are also linked into /usr/local/bin, so every tool is found
with the default PATH, not only with the image ENV. The build checks that
with env -i. Kaniko context is now ci/images so both images can COPY the
shared patch.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-09-27 21:33:12 +00:00
argus-bot (Paperclip service account) 780adadddc Merge pull request 'fix(agent-sandbox): pin v0.5.6 for Sandbox v1alpha1 (REN-298)' (#1050) from atlas/ren-298-agent-sandbox-v0.5.6 into master
ci/woodpecker/cron/alert-monitor Pipeline was successful
2026-09-27 21:16:17 +00:00
atlas-botandClaude Opus 5.5 38b7589c8d fix(agent-sandbox): pin v0.5.6 for Sandbox v1alpha1 (REN-298)
ci/woodpecker/pr/ci-scripts-test Pipeline was successful
ci/woodpecker/pr/ci-manifests-test Pipeline was successful
ci/woodpecker/pr/pr-review Pipeline was successful
The Paperclip Kubernetes sandbox plugin (0.1.0-alpha.1) hardcodes
agents.x-k8s.io/v1alpha1; v1.0.x serves only v1beta1, so the k8s-go
probe gets 404. v0.5.6 serves v1alpha1 (webhook conversion) and stores
v1beta1, the same storage version as v1.0.4.

- GitRepository tag and controller image -> v0.5.6 (digest pinned).
- Deployment: emptyDir for the self-signed webhook cert (read-only root).
- CiliumNetworkPolicy: allow kube-apiserver ingress (conversion webhook).
- Renovate: hold agent-sandbox below 1.0.0 until the plugin moves to v1beta1.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-09-27 21:14:10 +00:00
argus-bot (Paperclip service account) 2b9e599573 Merge pull request 'fix(ical-proxy): roll out main-926ead0 (2 MiB upstream body cap, REN-294)' (#1049) from atlas/ren-294-ical-proxy-926ead0 into master
ci/woodpecker/cron/alert-monitor Pipeline was successful
2026-09-27 20:47:07 +00:00
atlas-botandClaude Opus 5.5 1cd4b864ef fix(ical-proxy): roll out main-926ead0 (2 MiB upstream body cap)
ci/woodpecker/pr/ci-scripts-test Pipeline was successful
ci/woodpecker/pr/ci-manifests-test Pipeline was successful
ci/woodpecker/pr/pr-review Pipeline was successful
main-926ead0 includes ical-proxy PR #7 (REN-230): the upstream response
body is capped at 2 MiB, so an oversized feed gets 413 instead of being
buffered whole into a 256Mi pod. It also includes PR #10: upstream fetch
failures are logged with the host and answered with 502 instead of 500.

Refs: REN-294

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-09-27 20:45:38 +00:00
argus-bot (Paperclip service account) 56deab1e65 Merge pull request 'fix(ci): agent-runtime images in their own workflow (REN-286)' (#1048) from atlas/ren-286-agent-runtime-own-workflow into master
ci/woodpecker/push/build-ci-images Pipeline was successful
ci/woodpecker/push/build-agent-runtime Pipeline was successful
ci/woodpecker/cron/issue-fix Pipeline was successful
ci/woodpecker/cron/alert-monitor Pipeline was successful
2026-09-27 20:30:18 +00:00
atlas-botandClaude Opus 5.5 93778121f1 fix(ci): agent-runtime images in their own workflow (REN-286)
ci/woodpecker/pr/ci-scripts-test Pipeline was successful
ci/woodpecker/pr/ci-manifests-test Pipeline was successful
ci/woodpecker/pr/pr-review Pipeline was successful
On the #1046 merge (pipeline 11306) the build-agent-runtime step got no
pod: the full rebuild of build-ci-images.yml had filled the 24-CPU
woodpecker-ci-quota ("exceeded quota"), so the go image was never built.

Move the step to .woodpecker/build-agent-runtime.yml. It runs only when
ci/images/agent-runtime-*/** or its own file change, and can be re-run
alone with a deployment to target build-agent-runtime. Step content is
unchanged.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-09-27 20:26:17 +00:00
argus-bot (Paperclip service account) c7ebefdbec Merge pull request 'fix(agent-sandbox): drop invalid chart labels via postRenderer (REN-285)' (#1047) from atlas/ren-285-agent-sandbox-labels into master 2026-09-27 20:24:07 +00:00
argus-bot (Paperclip service account) aaadaf0d2f Merge pull request 'feat(ci): agent-runtime go and ops images for the k8s sandbox (REN-286)' (#1046) from atlas/ren-286-agent-runtime-images into master
ci/woodpecker/push/build-ci-images Pipeline failed
2026-09-27 20:22:57 +00:00
atlas-botandClaude Opus 5.5 8b2910674c fix(agent-sandbox): drop invalid chart labels via postRenderer (REN-285)
ci/woodpecker/pr/ci-manifests-test Pipeline was successful
ci/woodpecker/pr/ci-scripts-test Pipeline was successful
ci/woodpecker/pr/pr-review Pipeline was successful
HelmRelease agent-sandbox is Stalled (InstallFailed): the chart's common
labels render app.kubernetes.io/version from image.tag (contains the
digest, >63 chars) and helm.sh/chart with Flux's +<rev> suffix. Remove
both labels in a kustomize postRenderer. Selector and pod labels are
unaffected.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-09-27 20:21:21 +00:00
atlas-botandClaude Opus 5.5 a1ac4abe80 fix(ci): agent-runtime in one 1-CPU step; image builds on master only (REN-286)
ci/woodpecker/pr/ci-scripts-test Pipeline was successful
ci/woodpecker/pr/ci-manifests-test Pipeline was successful
ci/woodpecker/pr/pr-review Pipeline was successful
The first push of this branch started all 13 build steps: the push trigger
had no branch filter. 13 pods at the 2-CPU default limit exceeded the
24-CPU woodpecker-ci-quota, so the PR checks and one build failed.

- push trigger: branch master only
- go and ops build in one step, one pod, at 1 CPU: a full rebuild is 23 CPU

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-09-27 20:13:30 +00:00
atlas-botandClaude Opus 5.5 ee11744c08 feat(ci): agent-runtime go and ops images for the k8s sandbox (REN-286)
ci/woodpecker/pr/ci-manifests-test Pipeline failed
ci/woodpecker/pr/ci-scripts-test Pipeline failed
ci/woodpecker/pr/pr-review Pipeline failed
ci/woodpecker/push/build-ci-images Pipeline failed
Two pod images for the Paperclip Kubernetes sandbox (REN-284 step 2):
the stock agent-runtime-claude, pinned by digest, plus
- agent-runtime-go: Go 1.27.1, golangci-lint v2.14.0
- agent-runtime-ops: kubectl v1.36.5, flux v2.9.5, kustomize v5.8.1, helm 4.3.0

Tools are copied from their upstream images pinned by tag and digest, so
the existing Renovate dockerfile manager bumps them. Pushed to
konairius/agent-runtime-{go,ops}/agent-runtime-claude:v1 because the plugin
keeps that name and swaps only the registry prefix.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-09-27 20:09:29 +00:00
argus-bot (Paperclip service account) 80d9798132 Merge pull request 'feat(paperclip): install agent-sandbox, grant plugin rights on paperclip-renner (REN-285)' (#1045) from atlas/ren-285-agent-sandbox into master
ci/woodpecker/cron/alert-monitor Pipeline was successful
2026-09-27 20:02:48 +00:00
atlas-botandClaude Opus 5.5 7a9aa809f1 feat(paperclip): install agent-sandbox, grant plugin rights on paperclip-renner (REN-285)
ci/woodpecker/pr/ci-scripts-test Pipeline was successful
ci/woodpecker/pr/ci-manifests-test Pipeline was successful
ci/woodpecker/pr/pr-review Pipeline was successful
- infrastructure/agent-sandbox: Flux GitRepository (tag v1.0.4) + HelmRelease
  of the upstream in-repo chart; image pinned by digest, restricted
  securityContext, limits. CRDs via crds: CreateReplace.
- namespaces: agent-sandbox-system and paperclip-renner, both PSS restricted.
- network-policies: CNP for agent-sandbox-system (probes in, apiserver out).
- apps/paperclip/sandbox-rbac.yaml: Role + RoleBinding in paperclip-renner and
  a create-namespaces ClusterRole, bound to paperclip-prometheus-read (the SA
  the paperclip pod actually runs as; there is no SA `paperclip`).
- renovate.json: group the git tag and the image pin into one PR.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-09-27 19:59:37 +00:00
atlas-botandClaude Opus 5.5 997ffbbf9b feat(network-policies): scope paperless database/monitoring ingress per workload (REN-28 PR 2b)
ci/woodpecker/pr/ci-scripts-test Pipeline was successful
ci/woodpecker/pr/ci-manifests-test Pipeline was successful
ci/woodpecker/pr/pr-review Pipeline was successful
default-deny-ingress in the paperless namespace admitted the whole
`database` and `monitoring` namespaces on every port, on
endpointSelector:{} — so on paperless's HTTP listener too, which trusts
X-Authentik-Username from anything that connects. Both admits are
removed and the three load-bearing flows are kept as per-workload
policies:

  pprl-pg-allow-cnpg-operator  database/cloudnative-pg -> pprl-pg   :8000
  pprl-pg-allow-prometheus     monitoring/prometheus   -> pprl-pg   :9187
  paperless-allow-blackbox     monitoring/blackbox     -> paperless :8000

No ICMP rule on them (REN-144 option (a)); the baseline ICMP and the
host/remote-node L3 admit are untouched.

Also, per plan rev 8 §5 and REN-148:
- CNPNegativeControlReachable, a second group in
  prometheusrule-blackbox.yaml, scoped to job=blackbox-negative-control.
- Comment-only corrections of every citation of the removed
  #database-admit / #monitoring-admit anchors (paperless
  network-policy, probes-blackbox, gatus header, probes-ren28-negative),
  plus the IPv4-fallback and scrapeTimeout notes on the
  negative-control Probe (PR 2a review findings 1 and 2).

gatus ConfigMap data is byte-identical (sha256 unchanged); every changed
line in that file is a comment above `data:`.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-09-27 19:25:41 +00:00
argus-bot (Paperclip service account) ea51731207 Merge pull request 'feat(monitoring): canary the CephPoolLostRedundancy join (REN-93)' (#989) from atlas/ren-93-promql-gate into master
ci/woodpecker/cron/issue-fix Pipeline was successful
ci/woodpecker/cron/alert-monitor Pipeline was successful
2026-09-27 19:09:35 +00:00
atlas-botandClaude Opus 5.5 b03be79635 feat(monitoring): canary the CephPoolLostRedundancy join (REN-93)
ci/woodpecker/pr/ci-scripts-test Pipeline was successful
ci/woodpecker/pr/ci-manifests-test Pipeline was successful
ci/woodpecker/pr/pr-review Pipeline was successful
CephPoolLostRedundancy (critical) joins three metrics on `pool_id` and filters
on ceph_pool_metadata{type="replicated"}. If an upgrade or relabel renames the
label, the value, or the join key, the rule returns nothing and goes dark
silently. CephPoolLostRedundancyBlind is the same join with the thresholds
dropped, wrapped in absent(): warning, for: 1h to ride out mgr failovers.

Its six scenarios are a promtool suite at monitoring-rules/tests/ceph_test.yaml,
with five negative controls in mutations.txt, run by the existing `promtool`
step (#1026). The CI half of the original #989 is dropped: #1026 covers it.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-09-27 19:04:36 +00:00
argus-bot (Paperclip service account) 9e20e31a28 Merge pull request 'monitoring-rules: critical alerts for HA, recorder DB, Mosquitto, Zigbee2MQTT (REN-245)' (#1041) from atlas/ren-245-ha-critical-alerts into master
ci/woodpecker/cron/issue-fix Pipeline was successful
ci/woodpecker/cron/alert-monitor Pipeline was successful
2026-09-27 16:57:59 +00:00
atlas-botandClaude Opus 5.5 b5e67a93bf monitoring-rules: critical alerts for HA, recorder DB, Mosquitto, Zigbee2MQTT (REN-245)
ci/woodpecker/pr/ci-scripts-test Pipeline was successful
ci/woodpecker/pr/ci-manifests-test Pipeline was successful
ci/woodpecker/pr/pr-review Pipeline was successful
New PrometheusRule home-assistant with four `for: 5m`, severity critical
alerts. Before this the only signal for any of them was the cluster-wide
KubePodNotReady (15m, warning).

- HomeAssistantDown: HA scrape target down or absent.
- HomeAssistantRecorderDBUnhealthy: ha-pg has no primary with Postgres up,
  or fewer than spec.instances (2) instances with Postgres up.
- MosquittoDown: no Ready broker pod (bootstrap Job pods excluded).
- Zigbee2MQTTDownOrCoordinatorOffline: pod not Ready, or HA's
  bridge_connection_state sensor reads 0.

Each alert keeps one label set across its failure modes, so one outage
is one alert with one `for` timer. Unit suite and five negative controls
added; scripts/ci/promtool-rules.sh passes locally with promtool 3.15.0.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-09-27 16:49:38 +00:00
argus-bot (Paperclip service account) 76e05c0f26 Merge pull request 'docs: HA change window, HA-impact review, HA image rollback runbook (REN-243)' (#1040) from atlas/ren-243-ha-window into master
ci/woodpecker/cron/alert-monitor Pipeline was successful
2026-09-27 16:42:58 +00:00
svc-atlasandClaude Opus 5.5 8ef039f8a6 docs: HA change window, HA-impact review, HA image rollback runbook (REN-243)
ci/woodpecker/pr/ci-scripts-test Pipeline was successful
ci/woodpecker/pr/ci-manifests-test Pipeline was successful
ci/woodpecker/pr/pr-review Pipeline was successful
Owner decision on REN-240 (protection rule 5):
- README.md: disruptive work only 02:00-05:00 Europe/Berlin; PRs touching
  kubernetes/apps/home-assistant/ or cluster-wide disruptive changes need
  an HA-impact review (Hestia; owner until she exists).
- kubernetes/RUNBOOK-home-assistant-image-rollback.md: pin the previous
  HA tag in one commit (revert bump + drop the imagepolicy marker, so
  image automation does not re-bump it).

Docs only. No manifest changes.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-09-27 16:41:07 +00:00
k.renner bd03b61eb4 Merge pull request 'feat(openbao): secret-exists-check policy for Argus and Atlas' (#1039) from feat/openbao-secret-exists-check into master
ci/woodpecker/cron/issue-fix Pipeline was successful
Reviewed-on: k.renner/homelab#1039
2026-09-27 16:37:25 +00:00
argus-bot (Paperclip service account) 7841177fc6 Merge pull request 'feat(renovate): weekly Renovate runner; enable on homelab (REN-216)' (#1035) from atlas/ren-216-renovate into master 2026-09-27 16:36:56 +00:00
claude-botandClaude Opus 5.5 9abe2ac820 feat(openbao): secret-exists-check policy for Argus and Atlas
ci/woodpecker/pr/ci-scripts-test Pipeline was successful
ci/woodpecker/pr/ci-manifests-test Pipeline was successful
ci/woodpecker/pr/pr-review Pipeline was successful
Argus and Atlas need to verify that a cluster secret exists (for example
before reviewing or merging a PR that consumes it through an
ExternalSecret) without being able to read its value. The policy grants
read/list on homelab/metadata/* only: paths, versions and timestamps, no
data, no writes. Whole tree, per owner decision.

Identity is a userpass user (house precedent: claude-bot) whose password
is one Paperclip agent secret bound to both agents. Applied once by hand
with an admin token, like the other policies in this directory.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-09-27 18:36:42 +02:00
argus-bot (Paperclip service account) 89af8c355c Merge pull request 'fix(ical-proxy): roll out main-73b5d97 (WriteTimeout above fetch timeout)' (#1038) from atlas/ren-239-ical-proxy-main-73b5d97 into master
ci/woodpecker/cron/alert-monitor Pipeline was successful
2026-09-27 16:18:16 +00:00
atlas-botandClaude Opus 5.5 1e680eda4f fix(ical-proxy): roll out main-73b5d97 (WriteTimeout above fetch timeout)
ci/woodpecker/pr/ci-manifests-test Pipeline was successful
ci/woodpecker/pr/ci-scripts-test Pipeline was successful
ci/woodpecker/pr/pr-review Pipeline was successful
Bump the pinned ical-proxy image from main-4783abe to main-73b5d97.
The only change is konairius/ical-proxy #9 (REN-232): the server
WriteTimeout goes from 10s to 40s (30s upstream fetch timeout + 10s
headroom), so a slow-but-legitimate upstream is no longer cut off
before /proxy can write its response.

Refs: REN-239, REN-232

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-09-27 16:14:06 +00:00
argus-bot (Paperclip service account) 34b59175e2 Merge pull request 'feat(ical-proxy): roll out main-4783abe (SSRF guard + /proxy concurrency cap)' (#1037) from atlas/ren-238-ical-proxy-main-4783abe into master
ci/woodpecker/cron/alert-monitor Pipeline was successful
2026-09-27 16:12:14 +00:00
atlas-botandClaude Opus 5.5 782ce2617e feat(ical-proxy): roll out main-4783abe (SSRF guard + /proxy concurrency cap)
ci/woodpecker/pr/ci-manifests-test Pipeline was successful
ci/woodpecker/pr/ci-scripts-test Pipeline was successful
ci/woodpecker/pr/pr-review Pipeline was successful
Bump the pinned ical-proxy image from main-db90a59 to main-4783abe.
The new build adds two hardening changes from konairius/ical-proxy:

- #6: refuse upstreams and redirect hops that resolve to private,
  loopback, link-local or CGNAT addresses. Public redirects are still
  followed (up to 5).
- #8 (REN-231): cap concurrent /proxy upstream fetches at 20; requests
  over the cap get 429 + Retry-After instead of piling up goroutines.

Refs: REN-238, REN-231

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-09-27 16:10:44 +00:00
argus-bot (Paperclip service account) 7154a8dd3f Merge pull request 'fix(ical-proxy): pull the image from the Gitea registry (main-db90a59)' (#1036) from atlas/ren-201-ical-proxy-gitea-image into master
ci/woodpecker/cron/issue-fix Pipeline was successful
ci/woodpecker/cron/alert-monitor Pipeline was successful
2026-09-27 15:20:54 +00:00
atlas-botandClaude Opus 5.5 d6681702a9 fix(ical-proxy): pull the image from the Gitea registry (main-db90a59)
ci/woodpecker/pr/ci-scripts-test Pipeline was successful
ci/woodpecker/pr/ci-manifests-test Pipeline was successful
ci/woodpecker/pr/pr-review Pipeline was successful
ical-proxy moved from GitHub to Gitea and its image is now built by
Woodpecker and pushed to gitea.renner.uno/konairius/ical-proxy. The
ghcr.io image gets no new builds.

main-db90a59 has the same application code and Dockerfile as the
running main-99a912b; the commits in between touch only CI and docs.
The package pulls anonymously, so no imagePullSecret is added.

Revert: git revert this commit; Flux rolls the pods back to
ghcr.io/konairius/ical-proxy:main-99a912b.

Refs: REN-201

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-09-27 15:18:15 +00:00
atlas-botandClaude Opus 5.5 7be8ebab8d fix(renovate): also skip python-matter-server, the 33rd Flux-automated image (REN-216)
ci/woodpecker/pr/ci-scripts-test Pipeline was successful
ci/woodpecker/pr/ci-manifests-test Pipeline was successful
ci/woodpecker/pr/pr-review Pipeline was successful
Review of #1035: image-automation/ has 33 ImageRepositories, the
disable list had 32. Without this, Renovate and Flux would both bump
ghcr.io/matter-js/python-matter-server.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-09-27 14:50:53 +00:00
security-bot 3e71c32799 chore(image-automation): bump ghcr.io/home-assistant/home-assistant:2026.9.4
ci/woodpecker/cron/e2e Pipeline failed
ci/woodpecker/cron/security-scan Pipeline was successful
ci/woodpecker/cron/issue-fix Pipeline was successful
ci/woodpecker/cron/alert-monitor Pipeline was successful
Updates managed by image-automation-controller.
2026-09-27 10:40:26 +00:00
security-bot 79188fbb59 chore(image-automation): bump ghcr.io/paperclipai/paperclip:nightly@sha256:45f3e7fee1cb1a045854bce42ab189163d1dd573ba3b1b2a4c7469714ec29621
ci/woodpecker/cron/alert-monitor Pipeline was successful
Updates managed by image-automation-controller.
2026-09-27 10:25:54 +00:00
argus-bot (Paperclip service account) 8d5fc041bf Merge pull request 'ha-pg: dedicated walStorage 21Gi + primaryUpdateMethod switchover (REN-176)' (#1033)
ci/woodpecker/cron/issue-fix Pipeline was successful
ci/woodpecker/cron/alert-monitor Pipeline was successful
Reviewed and approved at b9a85474c0 (review #1117). Title corrected at merge: ships 21Gi, not 18Gi.
2026-09-27 09:00:57 +00:00
atlas-botandClaude Opus 5.5 d6fb88a464 feat(renovate): weekly Renovate runner for git.renner.uno; enable on homelab (REN-216)
ci/woodpecker/pr/ci-scripts-test Pipeline was successful
ci/woodpecker/pr/ci-manifests-test Pipeline was successful
ci/woodpecker/pr/pr-review Pipeline was successful
- apps/renovate: CronJob (daily 04:00, routine PRs Monday only via the
  shared preset's schedule), runner config, renovate-bot token ExternalSecret.
- clusters/homelab/renovate.yaml: dedicated Flux Kustomization with the
  ExternalSecret health check from uptime-monitor.yaml.
- infrastructure: `renovate` namespace, its CiliumNetworkPolicy (DNS,
  Traefik, world:443; no ingress, no API server), and the namespace in the
  openbao ClusterSecretStore allowlist.
- renovate.json: extends local>k.renner/renovate-config. Managers flux,
  kubernetes, woodpecker, dockerfile. Skips the images Flux image automation
  already bumps, and Flux's own gotk-components. Digest pins and
  Cilium/Rook-Ceph minors get their own PRs.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-09-27 07:10:49 +00:00
argus-bot (Paperclip service account) b58dea90f5 Merge pull request 'fix(monitoring): one WAL-archive rule, >5 for 20m; drop the depth rule (REN-152)' (#1019) from atlas/ren-152-wal-backlog-retune into master
ci/woodpecker/cron/issue-fix Pipeline was successful
ci/woodpecker/cron/alert-monitor Pipeline was successful
2026-09-27 06:41:11 +00:00
atlas-botandClaude Opus 5.5 26e9f85afd test(monitoring): regenerate cnpg-backup suite for the one-rule shape (REN-152)
ci/woodpecker/pr/ci-scripts-test Pipeline was successful
ci/woodpecker/pr/ci-manifests-test Pipeline was successful
ci/woodpecker/pr/pr-review Pipeline was successful
#1026 (REN-161) landed a promtool suite asserting CNPGWalArchiveBacklogSurge
and `for: 15m`, and mutations targeting `for: 8m`/`for: 15m`. This PR retires
the surge rule and moves the backlog rule to `> 5` for `20m`, so master CI
would break on merge.

- Generator: drop every Surge assertion; firing cases move to t=25m.
- New case 9: the worst night in Prometheus' 27-night retention (2026-09-11,
  peak 141) as raw 30s samples, 12m pending at a 1m evaluation step.
- mutations.txt: surge-for-2m/-5m removed; backlog-for-12m added (caught only
  by case 9, the margin control); backlog-for-30m retargeted at `for: 20m`.
- README and the woodpecker step comment updated to match.

Verified: scripts/ci/promtool-rules.sh with promtool 3.15.0 (CI's pin) —
18 manifests parsed, 2 suites green, 10 mutations caught;
scripts/ci/test-promtool-rules.sh passes.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-09-27 06:39:31 +00:00
atlas-botandClaude Opus 5 d39bcff92c fix(monitoring): one WAL-archive rule, >5 for 20m; drop the depth rule (REN-152)
Retune under Zeus's ruling on REN-152: the instrument is persistence, not
depth. This was meant to land on #1010 before it merged; #1010 merged
first, so this is the same change applied to master. Still
observability-only text — no expr semantics change, nothing restarts, no
storage and no traffic path is touched.

- CNPGWalArchiveBacklog `for`: 15m -> 20m.
- CNPGWalArchiveBacklogSurge (>64 for 8m) removed.

Why the depth rule goes. The failure that costs something is an archiver
that has stopped, and a stopped archiver sits wherever it stopped — it can
park at 8 segments and never approach 64, let alone 150. A threshold tuned
above the nightly envelope is blind to exactly the case the rule exists
for, and has to be raised again every time the recorder grows. It also had
no room left: measured across Prometheus' full 27-night retention rather
than the 7 nights it was built on, >64 for 8m fires once, on 2026-09-11.

Why 20m and not 15m. Same 27-night replay, 30s resolution, all 12 CNPG
instances. Only ha-pg-1 ever exceeds 5; every other instance peaks at 2.
Longest contiguous excursion above 5 is 13.0 minutes, on 2026-09-11 at a
peak of 141. Firing evaluations: 0 at 20m and also 0 at 15m, but 15m
leaves 2 minutes of margin where 20m leaves 7, and the nightly peak moved
116 -> 141 inside the measured month. The 5 minutes of added latency buy
nothing back: a real stall lasts hours, and at 32Gi the volume holds about
four nights of stalled WAL.

The description now says outright that the 02:14Z (04:14 local) burst is
normal and self-clearing, so a page means the backlog did not clear. The
drain-rate and headroom pointers (wal.maxParallel, spec.storage.size,
REN-135) move up from the deleted rule rather than being lost.

Verified with promtool 3.5.0 at evaluation_interval 30s against the rule
file as committed: the real 2026-09-11 series is silent; a stall at 8
segments fires; a backlog filling to 100 and not draining fires; a backlog
crossing a failover still fires on time, which is what `max by (namespace,
pod)` is for. Negative controls bracket the value — at `for: 12m` the real
burst fires, at `for: 25m` the stall cases stop firing.

Revert: `git revert` this commit. That restores exactly what is on master
today, >5 for 15m plus the Surge rule.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-09-27 06:36:44 +00:00
argus-bot (Paperclip service account) 2db8c217f6 Merge pull request 'feat(monitoring): alert when an ExternalSecret stops syncing (REN-103)' (#1002) from atlas/ren-103-eso-alert into master 2026-09-27 06:34:41 +00:00
argus-bot (Paperclip service account) 2d114a2dc6 Merge pull request 'monitoring: pin kube-prometheus-stack chart to 91.7.0 (REN-198)' (#1034) from atlas/ren-198-pin-kps-chart into master
ci/woodpecker/cron/e2e Pipeline failed
ci/woodpecker/cron/wiki-maintenance Pipeline was successful
ci/woodpecker/cron/issue-fix Pipeline was successful
ci/woodpecker/cron/alert-monitor Pipeline was successful
2026-09-26 20:35:45 +00:00
atlas-botandClaude Opus 5.5 36fba02a55 monitoring: pin kube-prometheus-stack chart to 91.7.0
ci/woodpecker/pr/ci-scripts-test Pipeline was successful
ci/woodpecker/pr/ci-manifests-test Pipeline was successful
ci/woodpecker/pr/pr-review Pipeline was successful
The version range >=72.0.0 let Flux upgrade the chart unattended
(91.5.2 -> 91.7.0 at 19:43 UTC on 2026-09-26, no git commit). That
restart moved Prometheus onto k8s-1 while its Ceph RBD mounts were
broken, causing a ~48 min alerting outage (REN-198).

Pinned to the version already deployed, so reconcile is a no-op.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-09-26 20:34:08 +00:00
atlas-botandClaude Opus 5.5 3c318c0584 test(monitoring): move the ESO suite under tests/ so REN-161's CI runs it
ci/woodpecker/pr/ci-scripts-test Pipeline was successful
ci/woodpecker/pr/ci-manifests-test Pipeline was successful
ci/woodpecker/pr/pr-review Pipeline was successful
promtool-rules.sh (REN-161, merged after this branch was opened) discovers
suites only as tests/*_test.yaml. At its old path the ESO suite would have
been skipped without a word. Moved, rule_files pointed at ../ for the
stripped mirror, the "inert until REN-96" header dropped, and five negative
controls added to mutations.txt: for 5m, sum-not-max, by-namespace,
no == 1, any condition. All five are caught.

promtool 3.15.0 (the CI pin): 18 manifests parsed, 2 suites green,
11 mutations caught. Rule file unchanged.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-09-26 16:17:06 +00:00
atlas-botandPaperclip 8ac19539a7 docs(monitoring): record the 8h flap baseline the 15m window was held for
Comment-only. The open question on this rule was whether the Ready condition
gauge flaps in ordinary operation, which could not be answered until #994 had
been collecting for a while. It has now run 464 consecutive scrapes since
00:18Z: all 52 ExternalSecrets reconciled (959 syncs), the gauge never reached
1 in any scrape, the error counter did not move, and the scrape target never
went down. Recorded in the rule file with the queries that produced it.

Also drops a reference to prometheusrule-ceph-test.yaml, which is on the
unmerged REN-96 branch and not in this repo, so it read as an in-repo
precedent a reviewer could not find.

Non-comment lines are byte-identical to 92dbc0de in both files, so the
promtool 2.53.2 check-rules and test-rules runs recorded on the PR still hold.

Co-Authored-By: Paperclip <noreply@paperclip.ing>
2026-09-26 16:16:21 +00:00
atlas-botandClaude Opus 5 8014272d2b docs(monitoring): record the live series counts the rule was checked against
Comment-only. The counts the rule's reasoning rests on are now measured on the
running Prometheus rather than derived from the repo: 105 series = 52
ExternalSecrets x 2 Ready polarities + 1 Deleted tombstone, across 20
namespaces, and the ExternalSecretSyncFailing expression returns empty today.
The last point is the one a reviewer wants: the rule arrives silent.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-09-26 16:16:21 +00:00
atlas-bot d6c0742783 docs(monitoring): show the ESO alert group actually re-notifies, and is not inhibited
Comment-only, again: `diff` of all non-comment lines against bbaf0c6a is empty.

Answers the grouping objection raised in review. Aggregating by
`exported_namespace` leaves these alerts without a `namespace` label, so they
share one Alertmanager group — but `group_interval: 5m` on the root route
notifies a group whose alert set has CHANGED, which is not `repeat_interval:
12h` re-sending an unchanged one. A second failing ExternalSecret therefore
mails within 5m rather than being swallowed. Records the receiver this rule
routes to and why it misses all four child routes.

Also records that the three inhibit rules cannot suppress it: all key on
`equal: ['namespace', 'alertname']` and nothing shares this alertname.
OpenBaoQuorumLost in particular does not inhibit it, and being critical at 2m
arrives first anyway.

Refs REN-103
2026-09-26 16:16:21 +00:00
atlas-bot 0f1b50ece8 docs(monitoring): record why the gauge beats the counter, with the live numbers
Comment-only. No rule, expression, `for:` window, label or annotation changes —
`diff` of all non-comment lines against the previous revision is empty, so
promtool's SUCCESS and the committed unit test still hold as run.

Argus's post-merge measurement on #994 raised the ESO sync-error counter as the
better primary signal, citing the 2026-09-20 `ai/wiki-embed-basic-auth`
incident as a case a Ready gauge would miss. Reading that incident back, it
argues the other way: the key needed a manual force-sync, so it never
self-healed and Ready=False was continuous for hours, which `for: 15m` catches
with a wide margin. It was a stuck condition, not a flap.

The measured counter data points the same way: `externalsecret_sync_calls_error`
has one series cluster-wide, `ai/wiki-anthropic` at 8 errors over 47 calls, on
an ExternalSecret that is Ready=True throughout — 8 counter events, zero sync
failures.

Also states plainly what `for: 15m` does not cover: a sync that fails and
recovers on its own inside the window, which is a deliberate choice because the
Secret ends up fresh and there is nothing for a human to do.

Refs REN-103
2026-09-26 16:16:21 +00:00
atlas-botandClaude Opus 5 33a8480f53 feat(monitoring): alert when an ExternalSecret stops syncing (REN-103)
Merge B of REN-103. #994 made the series exist; this is the rule built on
them. Split on purpose — the `for:` window had to be chosen against real
data, and Prometheus held 0 series for this metric until #994 landed.

Two corrections to what REN-100 specified, both found only once there was
data or source to read:

  * `exported_namespace`, not `namespace`. The metric carries its own
    `namespace` label and the PodMonitor attaches a target label of the same
    name, so Prometheus renames the metric's to `exported_namespace` and every
    live series reads `namespace="external-secrets"`. REN-100's expression
    still fires, and reports every failing ExternalSecret in the cluster as
    living in `external-secrets`. Found by Argus against the live data.

  * `max`, not `sum`. Both give 1 today on a single controller replica, but a
    Deployment rollout is briefly scraped as two pods, where `sum(...) == 1`
    evaluates to 2 and silently stops matching.

The condition gauge is the primary signal and `externalsecret_sync_calls_error`
is deliberately unused, which reverses the guess recorded on #994. The counter
increments on strictly more paths than the condition does — a failed Get of the
ExternalSecret, a failed Get or label Patch of the target Secret, an
unresolvable SecretStore — none of which call markAsFailed(). It is the noisier
signal, not the quieter one. The gauge does not flap: ESO sets it to 1 only in
markAsFailed() and clears it on the next successful reconcile, writing both
polarities every pass, so there is no unset state in between.

`for: 15m`, because a failed sync degrades freshness and not availability —
consumers keep the last Secret ESO wrote. Long enough to ride out a rolling
restart of the 3-replica OpenBao StatefulSet, and the real outage has its own
critical alert at 2m, so nothing is hidden by waiting.

Also adds a dead-man's-switch on `absent(externalsecret_status_condition)`.
Deleting the PodMonitor or reverting the `monitoring` ingress grant would
otherwise disarm the alert silently, which is the failure mode REN-103 exists
to end; TargetDown covers a target that is failing, not one that is absent.

Verified with promtool 2.53.2: `check rules` passes, and the committed
`-test.yaml` asserts the 15m window, the rendered namespace in the annotation,
the two-pod rollout case, that the `Deleted` tombstone never alerts, and that
the dead-man's-switch fires when the series vanish. Not yet evaluated against
the live Prometheus — this runner has no cluster access.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-09-26 16:16:21 +00:00
atlas-botandClaude Opus 5.5 b9a85474c0 ha-pg: walStorage 21Gi so stall survival matches today; note WAL left PGDATA (REN-176)
ci/woodpecker/pr/ci-manifests-test Pipeline was successful
ci/woodpecker/pr/ci-scripts-test Pipeline was successful
ci/woodpecker/pr/pr-review Pipeline was successful
Review #1114: 18Gi gave ~3.5 days of archiver outage, below the ~4.0 days
the shared 32Gi gives today. 21Gi gives ~4.1. The storage comment now says
WAL headroom moved to walStorage and 32Gi stays because PVCs cannot shrink.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-09-26 15:09:54 +00:00
argus-bot (Paperclip service account) 3d6169ec05 Merge pull request 'feat(monitoring): warn before Ceph nearfull — per-OSD and replicapool headroom (REN-163)' (#1025) from atlas/ren-163-ceph-nearfull-headroom into master
ci/woodpecker/cron/issue-fix Pipeline failed
ci/woodpecker/cron/alert-monitor Pipeline was successful
2026-09-26 15:09:31 +00:00
atlas-botandClaude Opus 5.5 df5e425b7c fix(cilium): drop cilium_policy_verdict_total, not a cilium 1.20.2 metric (REN-166)
ci/woodpecker/pr/ci-manifests-test Pipeline was successful
ci/woodpecker/pr/ci-scripts-test Pipeline was successful
ci/woodpecker/pr/pr-review Pipeline was successful
Argus's review of PR #1032: the name exists in neither pkg/ nor the metrics
docs for 1.20.2, and the agent skips unknown --metrics names silently. Zeus
dropped it from scope. metricsService, the Service delete and the new
selector stay.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-09-26 15:08:42 +00:00
atlas-botandClaude Opus 5.5 68527e8244 ha-pg: add dedicated walStorage 18Gi, switch primary on update (REN-176)
ci/woodpecker/pr/ci-manifests-test Pipeline was successful
ci/woodpecker/pr/ci-scripts-test Pipeline was successful
ci/woodpecker/pr/pr-review Pipeline was canceled
Owner-approved option B on REN-176. Adds a separate ceph-block WAL volume
per instance and sets primaryUpdateMethod: switchover so the pod roll this
triggers promotes the rolled replica instead of restarting the primary in
place.

Permanent: the CNPG 1.30.1 webhook rejects removing walStorage, so a git
revert of this commit fails admission. Merge only in an owner-named window.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-09-26 15:06:01 +00:00
atlas-botandClaude Opus 5.5 c7e61e7dce feat(cilium): enable cilium_policy_verdict_total, chart owns the metrics Service (REN-166)
ci/woodpecker/pr/ci-scripts-test Pipeline was successful
ci/woodpecker/pr/ci-manifests-test Pipeline was successful
ci/woodpecker/pr/pr-review Pipeline was canceled
- prometheus.metrics: +cilium_policy_verdict_total (opt-in; per-direction
  policy verdict attribution on top of cilium_drop_count_total).
- prometheus.metricsService: true, so the chart renders the headless
  `cilium-agent` metrics Service.
- Drop the hand-declared `cilium-agent-metrics` Service from
  cilium-servicemonitor.yaml and point the ServiceMonitor at the chart's
  Service, so the endpoints are scraped once, not twice.

This is a values change: helm-controller upgrades the CNI release, the
cilium-config `metrics` key changes, and the reloader annotation rolls the
agents node by node. Merge only inside the window Zeus set on REN-166.

Revert: git revert this commit; Flux restores the old Service and selector
and rolls the agents back the same way.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-09-26 15:03:58 +00:00
argus-bot (Paperclip service account) 0e2dea3ee2 Merge pull request 'fix(velero): read-only snapshot backup PVC for ceph-filesystem-bulk (REN-177)' (#1030) from atlas/ren-177-velero-cephfs-readonly-backuppvc into master 2026-09-26 15:01:11 +00:00
argus-bot (Paperclip service account) 7acdb36d52 Merge pull request 'uptime-monitor: attach owner's alert contacts to the pilot monitors (REN-7)' (#1031) from atlas/ren-7-alert-contacts into master
ci/woodpecker/cron/e2e Pipeline failed
ci/woodpecker/cron/security-scan Pipeline was successful
ci/woodpecker/cron/issue-fix Pipeline was successful
ci/woodpecker/cron/alert-monitor Pipeline was successful
2026-09-26 11:47:00 +00:00
atlas-botandClaude Opus 5.5 56e9814437 uptime-monitor: attach owner's alert contacts to the pilot monitors (REN-7)
ci/woodpecker/pr/ci-manifests-test Pipeline was successful
ci/woodpecker/pr/ci-scripts-test Pipeline was successful
ci/woodpecker/pr/pr-review Pipeline was successful
Both pilot EndpointMonitors were created with an empty alert_contacts
list, so they notified nobody. Set uptimeRobotConfig.alertContacts to the
two contacts every hand-made monitor in the account already uses
(7880965 e-mail, 8026823 type 13, threshold 0, recurrence 0), in the
order the API returns them so IMC's string comparison stays stable.

Per the owner's ruling on REN-138 no test alert is fired; delivery is
owner-verified. Revert this commit to return to empty contacts.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-09-26 11:45:53 +00:00
argus-bot (Paperclip service account) ff085a0586 Merge pull request 'ci: cite YAML by anchor instead of line number, and guard it (REN-183)' (#1027) from atlas/ren-183-yaml-anchors into master
ci/woodpecker/cron/issue-fix Pipeline was successful
ci/woodpecker/cron/alert-monitor Pipeline was successful
2026-09-26 10:38:26 +00:00
atlas-botandClaude Opus 5.5 25acbd4f1e fix(velero): read-only snapshot backup PVC for ceph-filesystem-bulk
ci/woodpecker/pr/ci-scripts-test Pipeline was successful
ci/woodpecker/pr/ci-manifests-test Pipeline was successful
ci/woodpecker/pr/pr-review Pipeline was successful
backupPVC in node-agent-config is keyed by source storage class.
ceph-filesystem-bulk had no entry, so its data-mover took the full
CephFS subvolume clone path and sat Pending on "unbound immediate
PersistentVolumeClaims" (4 min audiobookshelf, 22 min immich on
2026-09-26, paging KubePodNotReady). Growth with data would hit the
data-mover prepare timeout and fail the backup.

- node-agent-config: ceph-filesystem-bulk -> readOnly: true with
  storageClass ceph-filesystem-bulk-snapshot-readonly
- new StorageClass ceph-filesystem-bulk-snapshot-readonly:
  backingSnapshot "true" (shallow RO volume, no clone), reclaimPolicy
  Delete
- nodeAgent.podLabels revision label so node-agent restarts and loads
  the config (node-agent only, not the server)

Refs REN-177.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-09-26 10:35:39 +00:00
security-bot 5bdb29e1e0 chore(image-automation): bump ghcr.io/paperclipai/paperclip:nightly@sha256:1da39019a9b48c2b9318a5f037978765d226c8ef6838545fa691f3f8200bccac
ci/woodpecker/cron/alert-monitor Pipeline was successful
Updates managed by image-automation-controller.
2026-09-26 10:25:33 +00:00
k.renner 783a680184 Merge pull request 'feat(paperclip): LAN-only API door for external agents' (#1029) from feat/paperclip-api-door into master
ci/woodpecker/cron/issue-fix Pipeline was successful
ci/woodpecker/cron/alert-monitor Pipeline was successful
Reviewed-on: k.renner/homelab#1029
2026-09-26 09:24:20 +00:00
claude-botandClaude Opus 5.5 053e0f1a9b feat(paperclip): LAN-only API door for external agents
ci/woodpecker/pr/ci-manifests-test Pipeline was successful
ci/woodpecker/pr/ci-scripts-test Pipeline was successful
ci/woodpecker/pr/pr-review Pipeline was successful
Agents outside the pod (Claude Code on the workstation, via
`paperclipai agent local-cli` / agent API keys) only make outbound REST
calls to /api/* with Authorization: Bearer. The Authentik gate on
paperclip.renner.uno rejects those (intercept_header_auth), so they get a
separate machine door, following the wiki-index pattern:

- paperclip-api.renner.uno (no dns.renner.uno/public label: LAN-only)
  routes /api to the paperclip Service, bypassing the gate. Paperclip's
  bearer agent/board keys are the authentication.
- /api/auth on that host is refused (Traefik ipAllowList matching no
  address -> 403), so Better Auth password sign-in/sign-up stays behind
  the gate; upstream serves all password login under /api/auth.
- The host is added to PAPERCLIP_ALLOWED_HOSTNAMES (private-hostname
  guard would 403 it) and the CNP admits Traefik on 3100.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-09-26 11:21:48 +02:00
atlas-botandClaude Opus 5.5 21a7583523 ci: cite YAML by anchor instead of line number, and guard it (REN-183)
ci/woodpecker/pr/ci-manifests-test Pipeline was successful
ci/woodpecker/pr/ci-scripts-test Pipeline was successful
ci/woodpecker/pr/pr-review Pipeline was successful
Comments that pointed at other YAML as `file.yaml:N` went stale on any
edit above the cited line; three drift fixes had been merged by hand
(REN-181). The cited block now carries `# anchor: <name>` and the
comment cites `path.yaml#<name>`.

- Sweep: all 32 line-number citations in YAML comments converted.
  Several were already stale at head and now point at the right block
  (see PR). Vendored files (Flux gotk-components, IMC CRD) get no
  anchor; those two citations name the object/schema path instead.
- Guard: scripts/ci/yaml-citations.sh in ci-manifests-test.yml; fails
  on a line-number citation or a path#name whose file/anchor is gone.
  Self-test in ci-scripts-test.yml.
- CONTRIBUTING.md: the convention in three lines.

Comment-only under kubernetes/: every file parses to identical objects
before and after, so Flux applies nothing and no ConfigMap data changes.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-09-26 08:44:54 +00:00
argus-bot (Paperclip service account) 2608c264d3 Merge pull request 'ci(monitoring-rules): machine-check PromQL with promtool check rules + test rules (REN-161)' (#1026) from atlas/ren-161-promtool-ci into master
ci/woodpecker/cron/issue-fix Pipeline was successful
ci/woodpecker/cron/alert-monitor Pipeline was successful
2026-09-26 08:32:25 +00:00
argus-bot (Paperclip service account) bc1c69d356 Merge pull request 'Correct the "all six controllers" claim on gotk_reconcile_duration_seconds (comment-only)' (#1023) from atlas/ren-127-podmonitor-comment into master
ci/woodpecker/cron/alert-monitor Pipeline was successful
2026-09-26 08:26:04 +00:00
9a3c6ef9af ci(monitoring-rules): machine-check PromQL with promtool (REN-161)
ci/woodpecker/pr/ci-scripts-test Pipeline was successful
ci/woodpecker/pr/ci-manifests-test Pipeline was successful
ci/woodpecker/pr/pr-review Pipeline was successful
Nothing in this repo checked an alert expression. ci-manifests-test.yml proved
every PrometheusRule assembled into valid YAML and stopped there — no check that
an expression parses, that a label join matches anything, or that a `for` window
behaves the way its comment claims.

On REN-129 the CNPG surge rule was written `for: 2m` and reviewed at that value.
Against Iris's seven measured nights it fires on six of them: two owner emails a
night, 04:16 and 04:22 local, for a WAL backlog that clears itself in under ten
minutes. The arithmetic that caught it was hand-written from scratch twice, in
two runs, and thrown away both times because there was nowhere in the repo to
commit it. It is now a negative control.

Adds:

* scripts/ci/promtool-rules.sh — discovers every PrometheusRule (17 today),
  strips `spec:` into a temporary mirrored tree, runs `promtool check rules` on
  each, then `promtool test rules` over the committed suites. Discovery floors
  on both, as in the sibling steps.
* a `promtool` step in ci-manifests-test.yml, `depends_on: []` like the other
  four, on prom/prometheus:v3.15.0. The 3.x pin is load-bearing: the cluster
  runs kube-prometheus-stack >= 72.0.0, and alert `for` evaluation is
  version-sensitive, so a 2.x promtool would check a different evaluator than
  production. The script asserts the major version it is handed.
* kubernetes/apps/monitoring-rules/tests/ — the REN-129 suite (14 cases over
  the seven measured nights, an adversarial envelope built from the extremes of
  the measured fill/drain ranges, two stall shapes, a threshold boundary, a
  failover, a multi-instance case and the epoch-zero guard), its generator, and
  six negative controls in mutations.txt.
* a mutation phase. Each control breaks one value the rules depend on and the
  suites must fail; a control whose sed matches nothing is a failure, not a
  skip.
* scripts/ci/test-promtool-rules.sh, run from ci-scripts-test.yml — 17 cases
  asserting the script refuses to report success when it has checked nothing.

The mutation phase is not belt-and-braces, it is the point. Two failure modes
bit while writing this and neither changed promtool's exit code: a `rule_files`
entry that did not resolve, where promtool WARNs, loads zero rules, and passes
every `exp_alerts: []` assertion against an empty rule set; and traces generated
against the wrong clock window, where all seven nights were flat zero. Both were
green. A suite that passes proves the rules match the assertions, not that the
assertions reach the rules.

Production: nothing applied to the cluster. No manifest changed, so the
monitoring-rules kustomization builds identically — its `resources:` list is
explicit, and the new tests/ directory is not in it and has no kustomization.yaml
of its own, so Flux does not see it. Worst case is a red step on PRs touching
kubernetes/**; enable_status_check is false on master, so it cannot block a merge
on its own.

Verified with real promtool 3.15.0 against the real tree: 17 manifests parsed
(56 rules), the suite green, all 6 mutations caught. Run again under BusyBox
1.35.0 sh/awk/sed/find/xargs, the toolchain prom/prometheus actually ships.
Guard tests 17/17 under both bash and BusyBox sh. shellcheck 0.11.0 clean at
every severity. woodpecker-cli 3.18.0 lint clean on all 17 pipeline files.
Not run in Woodpecker itself — this PR is its first real pipeline execution.

Revert: revert this commit. It adds files and one step; nothing else reads them.

Co-Authored-By: Paperclip <noreply@paperclip.ing>
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-09-26 08:25:59 +00:00
argus-bot (Paperclip service account) a003e1c126 Merge pull request 'test(uptime-monitor): restore the audiobooks EndpointMonitor, and correct the 403 reading — REN-7' (#1024) from atlas/ren-7-restore-audiobooks into master 2026-09-26 08:18:37 +00:00
argus-bot (Paperclip service account) 25b6fa573f Merge pull request 'docs(monitoring-rules): repoint stale gatus citation 176-185 -> 205-214 (REN-128)' (#1008) from atlas/ren-128-probes-blackbox-citation into master
ci/woodpecker/cron/alert-monitor Pipeline was successful
2026-09-26 08:14:37 +00:00
8d2323b347 feat(monitoring): warn before Ceph nearfull, per-OSD and replicapool (REN-163)
ci/woodpecker/pr/ci-scripts-test Pipeline was successful
ci/woodpecker/pr/ci-manifests-test Pipeline was successful
ci/woodpecker/pr/pr-review Pipeline was successful
Ceph's mon_osd_nearfull_ratio is 0.85 and nothing reported the approach to
it, so the first signal would have been Ceph flagging nearfull — already the
incident. With failureDomain host, size 3 and three OSDs there is no
rebalance to hide behind: all three cross together.

Two warning rules, both observability only:

- CephOSDNearfullApproaching: fullest OSD sustained >= 75% for 30m. 0.75 is
  0.85 minus the largest measured bulk burst (+10.24 pp in 25 min, 09-26
  05:18-05:43Z), so it marks the point where one more such burst reaches
  nearfull. 30m is the shortest wait that outlives a self-reclaiming burst
  (that burst held >= 75% for 19.0 min) and short enough to fire before 0.85
  at the fastest observed sustained climb (+11.44 pp/h).

- CephReplicapoolHeadroomLow: replicapool max_avail < 160 GiB for 30m.
  160 = 89 GiB held above the 0.85 line + 38 GiB ha-pg has not yet consumed
  of its approved 32Gi + 35 GiB observed replicapool churn.

Replayed against the 14d of real series to 2026-09-26 08:00Z: both fire zero
times. Worst 30m-sustained OSD floor 71.632%; lowest 30m-sustained
replicapool ceiling 208.97 GiB. Both expressions evaluated against live
Prometheus at the 09-26 05:40Z peak do select (3 OSDs at 81.87%,
replicapool at 117.41 GiB), so the 30m `for` is what keeps that excursion
quiet, not a join that never matches.

Thresholds are unmerged pending the owner's yes on REN-163.

Co-Authored-By: Paperclip <noreply@paperclip.ing>
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-09-26 08:11:45 +00:00
argus-bot (Paperclip service account) ea0abda79c Merge pull request 'fix(uptime-monitor): fail only on the ESO reasons that never retry (REN-106)' (#999) from atlas/ren-106-narrow-eso-failed into master 2026-09-26 08:10:58 +00:00
atlas-botandClaude Opus 5 8967db1001 test(uptime-monitor): restore the audiobooks EndpointMonitor, and correct the 403 reading — REN-7
ci/woodpecker/pr/ci-manifests-test Pipeline was successful
ci/woodpecker/pr/ci-scripts-test Pipeline was successful
ci/woodpecker/pr/pr-review Pipeline was successful
Criterion 3 passed: the removal test (#1018, merged 101c11f4) deleted monitor
804092841 and the controller logged `Monitor Removed` at 03:57:58Z. This commit
is the deliberate revert of that test, which Zeus sequenced to run only after
the cap reading below. The restored object is byte-identical at the object level
to the version that provably created 804092841.

It also corrects a wrong claim this file asserted. The header stated that a
monitor-count cap was EXCLUDED as the cause of the `www.renner.uno` 403, on the
reasoning that a cap would arrive as HTTP 200 + `stat: fail`. The removal test
refuted that:

  03:26:27-03:56:27  account 10/10, seven consecutive `Status Code: 403`
  03:57:58           804092841 deleted, account 9
  04:01:27           `Monitor Added: www.renner.uno-uptime-monitor`, id
                     804092931, account back to 10

One freed slot is the only variable. UptimeRobot returns HTTP 403 when the
account monitor limit is reached, so "account is full" is the first hypothesis
for an IMC 403, not a discarded one. Capacity is now settled on fact for
REN-158; REN-8's 18-monitor page against a cap of 10 stays blocked on it.

Expect this restored create to be refused with 403 until the tier is raised —
`www` took the freed slot. Left in git per the capacity ruling so the retry loop
creates it unaided once capacity exists. `audiobooks.renner.uno` stays covered
by its 60s Gatus check throughout, so there is no coverage gap.

Also recorded: the real delete log string is `Removing monitor … from provider`
/ `Monitor Removed`, not the `Deleting Monitor` this file predicted; and the
status page is in all-monitors mode, proven in both directions (9->10 on create,
10->9 on prune) with no API key, which settles REN-9's monitor-list mode.

Verified: js-yaml loadAll gives 2 EndpointMonitors in `uptime-monitor`; the only
functional changed line is the restored object, every other changed line is a
comment; restored spec compared equal to `f20fe8bf^`. Not applied — Flux applies
from master and I cannot merge my own work.

Revert: revert this commit. Flux prunes the object and, because its monitor does
not exist, nothing in UptimeRobot changes.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-09-26 08:08:29 +00:00
ee4ea92a9e Correct the "all six controllers" claim on gotk_reconcile_duration_seconds
ci/woodpecker/pr/ci-manifests-test Pipeline was successful
ci/woodpecker/pr/ci-scripts-test Pipeline was successful
ci/woodpecker/pr/pr-review Pipeline was successful
#992's header comment says RecordDuration "IS called, by all six controllers",
established by grepping the tagged upstream source trees. Now that the scrape is
merged the claim is measurable, and five of six emit the family: 170 series from
kustomize (33), source (43), image-reflector (68), helm (25) and image-automation
(1), and zero from notification-controller.

Five is permanent, not today-only. notification-controller's three reconcilers
are registered but never walked -- controller_runtime_reconcile_total for
controller=alert/provider/receiver reads 0 over 56 h of uptime with 2 Alerts and
1 Provider live in the apiserver -- so the family is absent from its /metrics
entirely and creating a Flux Alert or Provider does not produce the sixth series.

Comment-only. Every one of the 17 changed lines is a pure comment line and the
comment-stripped file is byte-identical to master (same sha256), so the object
Flux applies is unchanged and no pod rolls.

Refs REN-127, REN-102, REN-97

Co-Authored-By: Paperclip <noreply@paperclip.ing>
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-09-26 08:08:03 +00:00
k.renner f96f04cd9d make paperclip externaly accasable
ci/woodpecker/cron/issue-fix Pipeline was successful
ci/woodpecker/cron/alert-monitor Pipeline was successful
2026-09-26 07:42:38 +02:00
argus-bot (Paperclip service account) 101c11f476 Merge pull request 'test(uptime-monitor): remove the audiobooks EndpointMonitor — REN-7 criterion 3 removal test' (#1018) from atlas/ren-7-delete-test-audiobooks into master
ci/woodpecker/cron/alert-monitor Pipeline failed
ci/woodpecker/cron/issue-fix Pipeline was successful
2026-09-26 03:56:13 +00:00
c2afbcdd4d docs(monitoring-rules): repoint stale gatus citation 176-185 -> 205-214 (REN-128)
ci/woodpecker/pr/ci-scripts-test Pipeline was successful
ci/woodpecker/pr/ci-manifests-test Pipeline was successful
ci/woodpecker/pr/pr-review Pipeline was successful
probes-blackbox.yaml:209 cited apps/gatus/configmap.yaml:176-185 as the
place gatus documents the paperless blind spot. That was true at cb9e73bd,
where the sentence was written. A later +29-line insert into configmap.yaml
pushed the block down; at master those lines are now Web Service 9
(music.renner.uno), which carries no prose at all.

The same 10-line Paperless blind-spot comment now runs 205-214.

Comment-only. No spec, no pod template, no new resource.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Co-Authored-By: Paperclip <noreply@paperclip.ing>
2026-09-26 03:55:53 +00:00
argus-bot (Paperclip service account) 5f8b6ca0a9 Merge pull request 'feat(monitoring): Flux per-object readiness via kube-state-metrics (REN-102)' (#1013) from atlas/ren-102-flux-ksm-crs into master
Reviewed and merged by argus-bot (REN-145). Approved at head 088db00e.

Independently verified: the eight GVKs against the single served CRD version in Flux v2.9.5; every CRD field path the config reads; object census = 149 and the reconcile intervals behind the 2h/1h thresholds; the rendered chart keeps --resources and omits --custom-resource-state-only; the whole rendered ClusterRole uses only list+watch with no wildcard; the real kube-state-metrics v2.20.0 binary accepts the rendered config while a malformed control is rejected at startup; the kustomize CI gate green on the simulated merge result, which CI itself did not test.

Own promtool fixtures: 9 alert tests plus a 13.5-day recording-rule simulation, all passing. Warm-up guard empty at 1201 samples and populated at 1297; the pruning case yields 0 under the shipped comparator against 1.1376 under the withdrawn ratio; tag counting survives a kube-state-metrics pod roll.

The missing staleness alert is an accepted, measured reduction; follow-ups tracked in REN-143.

Revert: git revert -m 1 <this merge commit>. Both Kustomizations are prune: true, so nothing is orphaned.
2026-09-26 03:54:03 +00:00
argus-bot (Paperclip service account) 15e81f8301 Merge pull request 'fix(cilium): declare the agent metrics Service so cilium_* is scraped (REN-147)' (#1017) from atlas/ren-147-cilium-agent-metrics-service into master
Reviewed by argus-bot (four-eyes: authored by atlas-bot, merged by argus-bot).

Verified against the PR head 17c1dece:
- helmrelease.yaml diff is comments only; parsed YAML of HEAD^ and HEAD is byte-identical (1683 bytes each). No values change, so no helm upgrade and no cilium agent restart.
- ServiceMonitor selector {managed-by: homelab, name: cilium-agent} matches only the new Service; endpoint port `metrics` exists on it; targetLabels k8s-app=cilium present.
- Service selector k8s-app: cilium, headless, distinct name from the chart's cilium-agent Service - no double-scrape or ownership collision if a chart flag is flipped later.
- Revert is one step: the monitoring-rules Flux Kustomization has prune: true, so git revert removes the Service.
- ci-manifests-test and ci-scripts-test green; advisory review-bot: no blocking issues.

REN-156
2026-09-26 03:53:28 +00:00
argus-bot (Paperclip service account)andPaperclip ec7a82eca9 feat(home-assistant): grow ha-pg storage 20Gi -> 32Gi (REN-141) (#1014)
Approved by argus-bot at head c1b9b259 after re-review (head moved from dd6720f2).
Ceph capacity gate cleared at 03:49Z: replicapool max_avail 168.8 GiB usable, per-OSD 76.1% -> 78.8% worst case against nearfull 0.85, HEALTH_OK.
Four eyes: authored by atlas-bot, merged by argus-bot.
PVCs do not shrink - manifest reverts with git revert <merge-sha> -m 1, volumes do not.

Co-Authored-By: Paperclip <noreply@paperclip.ing>
2026-09-26 03:52:21 +00:00
argus-bot (Paperclip service account) d9e54b40e9 Merge pull request 'feat(monitoring): make a stalled WAL archiver reportable (REN-129)' (#1010) from atlas/ren-129-wal-archive-backlog-visibility into master
Approved at 7aff5250 (review 1086). CNPGWalArchiveBacklog for: 30m -> 15m; new CNPGWalArchiveBacklogSurge > 64 for 8m; both exprs wrapped in max by (namespace, pod) so a failover does not restart the for timer.

Verified with promtool 3.5.0: 12-case test rules suite over Iris's seven measured nights plus an adversarial envelope case, all passing, with five negative controls each failing. Revert tested: git revert restores the file byte-for-byte.

Closes REN-129.
2026-09-26 03:51:58 +00:00
atlas-botandClaude Opus 5 f20fe8bf61 test(uptime-monitor): remove the audiobooks EndpointMonitor — REN-7 criterion 3 removal test
ci/woodpecker/pr/ci-manifests-test Pipeline was successful
ci/woodpecker/pr/ci-scripts-test Pipeline was successful
ci/woodpecker/pr/pr-review Pipeline was successful
Deletes the `audiobooks.renner.uno` EndpointMonitor so that the other half of
REN-7 can be proven: an EndpointMonitor creates an UptimeRobot monitor, and
deleting it removes that monitor again. "A monitor that cannot be removed is a
leak." The create side is already shown — monitor 804092841, created
2026-09-26 03:26:27, controller log `Monitor Added`.

What to observe after this merges, keyless and from either side:

  * `https://uptime.renner.uno/api/getMonitorList/UgMXmP1iRV` goes from
    `psp.totalMonitors: 10` to `9`, and id 804092841 is absent.
  * controller log: `Deleting Monitor: audiobooks.renner.uno-uptime-monitor`.

Precondition, checked before writing this: v2.2.13 carries no finalizer, so a
delete while the controller is down is never reconciled and orphans the monitor
permanently. Pod ingressmonitorcontroller-5d577cc58-pgqwg was Ready=True with
0 restarts. Whoever merges this must re-check that the pod is Ready first.

Also records, in the file, why the second pilot object still has no monitor:
UptimeRobot answers its create with HTTP 403 and IMC retries every 300s
forever. 403 is the non-200 branch of `Add()`, so it is not the provider's
validation path — that returns 200 with `stat: fail` — which rules out the
duplicate-URL, monitor-cap and bad-parameter guesses. Tracked on REN-155; the
object is left in place as the reproducer.

Blast radius: removes one EndpointMonitor from `uptime-monitor` and one
UptimeRobot HTTP check every 300s. No Ingress, workload, ingress controller,
DNS record or RBAC rule is touched, and `www.renner.uno` is unchanged.

Revert: revert this commit. Flux re-applies the object and the controller
re-creates the monitor under the same friendly name — a new id, since the name
and not the id is what binds object to monitor. That round trip is also the
idempotent-reconcile check and is worth doing deliberately.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-09-26 03:50:54 +00:00
c1b9b259b6 docs(home-assistant): correct the WAL stall attribution in ha-pg sizing (REN-141)
ci/woodpecker/pr/ci-manifests-test Pipeline was successful
ci/woodpecker/pr/ci-scripts-test Pipeline was successful
ci/woodpecker/pr/pr-review Pipeline was successful
The sizing comment blamed the 10-minute archiving stall on Velero repository
maintenance. REN-136 disproves that over seven nights:

  - sustained archiver drain is ~14 segments/min, flat whether Kopia is
    running or not, so Kopia does not slow the drain;
  - Kopia's nearest batch drifts across 02:03-02:24Z while the burst stays
    pinned to 02:13Z, and a cause that drifts 20 minutes cannot produce an
    effect fixed to the minute.

The real driver is a nightly producer burst: 56-119 segments queued at
02:13-02:15 UTC on all seven nights, against a steady-state queue of 0.
Comment now states that, and adds REN-136's stalled-night framing (6.36 GiB
free survives one stalled night, ~18.6 GiB carries about four).

Comment text only. `spec.storage.size: 32Gi` is unchanged and still the sole
semantic change on this branch — verified by parsing origin/master and HEAD
with js-yaml: with spec.storage.size masked the two parse to identical
objects.

Raised by Argus in review of #1014 as a non-blocking finding.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Co-Authored-By: Paperclip <noreply@paperclip.ing>
2026-09-26 03:47:59 +00:00
argus-bot (Paperclip service account) 02a23d1670 test(monitoring): negative-control Probe for paperless ingress scoping (REN-28 PR 2a) (#1016)
Reviewed at head 3b96b3ab, test-merged clean into master dd2256ea (tree af52adab).

Verified: one file +73/-0; 0 YAML parse failures repo-wide; jobName blackbox-negative-control unique; all four ports re-derived from the paperless Service/Cluster objects; tcp_connect module declared; paperless-ns.yaml still admits monitoring namespace-wide so the controls read 1 today.

Pages nobody: all 16 PrometheusRules enumerated, the only non-job-pinned probe_success rule (HetznerBackupEndpointDown) is instance-pinned to the Hetzner URL; the chart's up-based TargetDown cannot fire because blackbox answers 200 with probe_success 0 and the 5s module timeout stays inside the 10s scrapeTimeout; all 5 blackbox-overview.json panels are pinned to job=blackbox-http; no Grafana-managed alert references probe_success.

Monitoring-only, no traffic-path change. Revert with: git revert -m 1 <this-sha> on a branch, through a PR.

REN-28 §6.4 gate NOT yet taken - reviewer has no Prometheus credential either. PR 2b must not open until the probe_success == 1 reading exists.
2026-09-26 03:46:43 +00:00
17c1dece48 fix(cilium): declare the agent metrics Service so cilium_* is scraped (REN-147)
ci/woodpecker/pr/ci-manifests-test Pipeline was successful
ci/woodpecker/pr/ci-scripts-test Pipeline was successful
ci/woodpecker/pr/pr-review Pipeline was successful
The cilium chart renders templates/cilium-agent/service.yaml only when
prometheus.enabled AND (prometheus.serviceMonitor.enabled OR
prometheus.metricsService). infrastructure/cilium/helmrelease.yaml sets the
first and neither of the second, so no cilium-agent Service existed. The
standalone ServiceMonitor in apps/monitoring-rules selected a Service that was
never there: scrape pool serviceMonitor/kube-system/cilium-agent/0 sat at 0
active / 46 dropped targets and cilium_* had zero series.

Consequence: CiliumBPFMapPressureHigh and CiliumBPFMapFull read
cilium_bpf_map_pressure, so both evaluated an empty vector and could never
fire — the exact failure the helmrelease comment says the metrics were turned
on to prevent. cilium_policy_verdict_total and cilium_drop_count_total were
equally absent, which is why REN-140 needed a purpose-built prober to observe
a network-policy deny.

Declares a sibling metrics Service next to the ServiceMonitor instead of
setting prometheus.metricsService in the HelmRelease. The flag is the
chart-native fix and renders exactly this one object, but it is a values
change: helm-controller would upgrade the CNI release and three-way-merge
against live objects, and the configmap.reloader annotation turns any
resulting cilium-config change into a rolling restart of every agent. A
Service applied by the apps Kustomization cannot do that.

Naming follows authentik-outpost-servicemonitors.yaml: distinct name plus
app.kubernetes.io/managed-by: homelab, with the ServiceMonitor selector pinned
to it, so turning either chart flag on later neither collides on ownership nor
double-scrapes the same endpoints.

The helmrelease.yaml change is comment only — verified by rendering the chart
against the values block before and after: byte-identical, so Flux performs no
helm upgrade.

Co-Authored-By: Paperclip <noreply@paperclip.ing>
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-09-26 03:44:02 +00:00
argus-bot (Paperclip service account) dd2256ea05 test(monitoring): temporary negative-test probes for REN-28 §7 (REN-140) (#1015)
ci/woodpecker/cron/alert-monitor Pipeline was successful
Reviewed and merged by argus-bot (REN-149). Author atlas-bot; four-eyes split intact.

Verified live: no alerting rule can match job="blackbox-ren28-negative" (24 probe_/up/scrape_ rules enumerated; tcp_connect module timeout 5s < scrapeTimeout 10s keeps up==1); pod IPs 10.244.4.166/10.244.2.220 current; probeSelector strict so the release label is load-bearing and is set; monitoring has no egress enforcement.

Temporary. Delete probes-ren28-negative.yaml and its kustomization line once the REN-28 "after" reading is recorded.

Revert: git revert -m 1 <this sha>
2026-09-26 03:43:58 +00:00
argus-bot (Paperclip service account) d3f20d6d16 Merge pull request 'feat(netpol): scope the navidrome monitoring ingress to blackbox-exporter (REN-28)' (#1012) from atlas/ren-28-navidrome-monitoring-scope into master
ci/woodpecker/cron/issue-fix Pipeline was successful
REN-28 item 3a. Narrows the navidrome baseline CNP's whole-monitoring-namespace, every-port ingress admit to the blackbox-exporter pod on :4533 and :8686, and repoints two comments elsewhere in the tree that cited the replaced rule.

Reviewed by argus-bot at head 1c1a637c in a private detached worktree. ci-manifests-test and ci-scripts-test green at that head. Blocking review 1065 (a false ICMP justification) resolved by deletion in 1c1a637c.

Revert: git revert -m 1 <this sha>, through a PR.
2026-09-26 03:40:22 +00:00
7aff525001 feat(monitoring): make a stalled WAL archiver reportable (REN-129)
ci/woodpecker/pr/ci-manifests-test Pipeline was successful
ci/woodpecker/pr/ci-scripts-test Pipeline was successful
ci/woodpecker/pr/pr-review Pipeline was successful
ha-pg-1 queues WAL for archiving every night: flat 0 until 02:12Z, peak
02:14-02:15Z, drained by 02:22Z, peaks of 56-119 segments on the seven
nights measured 2026-09-19 to 2026-09-26. Point-in-time recovery for
home-assistant is degraded for the ~10 minutes each burst lasts. Nothing
fires, because CNPGWalArchiveBacklog's `for` was 30m.

The cause is a write burst, not IO contention. Drain was a flat 13.0-14.9
segments/min on all seven nights, including the night whose Kopia
repository-maintenance batch started only after the burst had drained;
that batch drifts across 02:03-02:24Z while the peak stays pinned to
02:15Z. Fill is what varies, 18.7-39.7 segments/min. 02:12Z is 04:12
local, when Home Assistant's recorder purge runs. An earlier revision of
this commit named Velero/Kopia as the cause; the 7-night data retracts
that, and the annotations no longer send anyone to the velero namespace.

Three changes, all alert-rule text. Nothing restarts, no storage and no
traffic path is touched.

- CNPGWalArchiveBacklog `for`: 30m -> 15m. This does not fire on the
  nightly burst at either value, and should not: every burst in the week
  drained itself, and the longest contiguous excursion above 5 was 10
  minutes. 15m is for the archiver that has actually stopped, which is
  the failure that fills the PVC and stops Postgres.

- New CNPGWalArchiveBacklogSurge, >64 segments (1 GiB) for 8m, warning.
  Covers the shape the 15m rule cannot see: a working archiver outrun by
  production. 8m because the measured envelope spends at most 5
  consecutive minutes above 64 on any night, so 8m clears the worst
  observed night by 3 minutes while still catching 1 GiB that is not
  draining -- from 119, a healthy archiver is back under 64 inside 5
  minutes.

- Both exprs wrapped in `max by (namespace, pod)`. `role` flips on
  failover, a changed label is a new series, and a new series restarts
  the `for` timer. On the raw series a backlog that persists through a
  failover at minute 11 is silent at 16m and 20m and only pages by 25m.

Verified with promtool 3.6.0 against the measured traces, not applied to
the cluster: `check rules` passes, and unit tests cover the ordinary
night, the worst night, the quiet night, a stalled archiver, and a role
flip mid-backlog. Negative controls confirm the tests have teeth -- at
`for: 2m` the surge rule fires at 02:17Z with $value 99 on the ordinary
night, and without `max by` the role-flip case fails.

Revert: `git revert <this commit>` restores both rules exactly. No state
outside Prometheus's rule evaluation is affected either way.

Co-Authored-By: Paperclip <noreply@paperclip.ing>
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-09-26 03:37:15 +00:00
3b96b3ab1c feat(monitoring): negative-control Probe for paperless ingress scoping (REN-28 PR 2a)
ci/woodpecker/pr/ci-manifests-test Pipeline was successful
ci/woodpecker/pr/ci-scripts-test Pipeline was successful
ci/woodpecker/pr/pr-review Pipeline was successful
Adds one Probe, `blackbox-negative-control-paperless`, with its own jobName
`blackbox-negative-control` and four tcp_connect targets in the `paperless`
namespace. The targets exist to be REFUSED: each must read probe_success == 1
at this commit and 0 once REN-28 PR 2b narrows the whole-namespace `monitoring`
admit in paperless-ns.yaml. That flip is the negative test, and it then stays
on as a standing regression alarm.

This is monitoring-only. No traffic-path change, no restart, no new grant, no
policy edit. blackbox-exporter already runs in `monitoring`, whose baseline CNP
is ingress-only, and default-deny.yaml is scoped `namespace: apps`, so the
paperless ingress policy is the only variable that can move these controls.

Deliberately silent: both blackbox alerts are scoped job="blackbox-http", so a
distinct jobName is outside them and four permanently-failing targets page
nobody after 2b. The inverted alert CNPNegativeControlReachable ships in PR 2b,
not here — between 2a and 2b these controls are supposed to read 1.

Appended at end of file so existing line-number citations (including
paperless-ns.yaml's reference to probes-blackbox.yaml:250) do not shift.

Refs REN-28 §5.6, §6.4. Revert: drop this one Probe document.

Co-Authored-By: Paperclip <noreply@paperclip.ing>
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-09-26 03:34:55 +00:00
atlas-botandPaperclip 1c1a637c66 fix(netpol): drop the entity-scoped ICMP allow from navidrome (REN-144)
ci/woodpecker/pr/ci-manifests-test Pipeline was successful
ci/woodpecker/pr/ci-scripts-test Pipeline was successful
ci/woodpecker/pr/pr-review Pipeline was successful
The `fromEntities: cluster` + `icmps` rule added earlier in this branch was
justified by a false premise. Its comment claimed the new `toPorts` was "the
first layer 4 ingress rule in this namespace" — at f177685d the ingress already
ended in an `icmps:` rule, which is itself a layer 4 rule. So the allow was
neither required by this change nor new with it.

It also did not match its own header ("ICMP from the host and the other nodes"
vs `fromEntities: cluster`), and for pods it was redundant: IPv4 type 3 and
IPv6 types 1 and 2 are already in the namespace-wide ICMP rule below it.

ha-pg-allow-cnpg-operator does not transfer as precedent: it is pod-scoped and
carries no `host`/`remote-node` allow, so `cluster` is the only thing admitting
the host there. Four peer baselines with exactly this shape — monitoring,
home-assistant, ai, external-secrets — carry no entity-scoped ICMP allow, and
monitoring is where blackbox-exporter and Prometheus themselves run.

The branch is now exactly the approved REN-28 §4.1 scope: the monitoring
namespace admit is narrowed to the blackbox-exporter pod on 4533/8686, and
nothing else in navidrome-ns.yaml changes.

Revert: `git revert` this commit restores the allow; reverting the whole PR
restores the namespace-wide monitoring admit.

Co-Authored-By: Paperclip <noreply@paperclip.ing>
2026-09-26 03:33:25 +00:00
6ee36d9f61 test(monitoring): temporary negative-test probes for REN-28 §7 (REN-140)
ci/woodpecker/pr/ci-manifests-test Pipeline was successful
ci/woodpecker/pr/ci-scripts-test Pipeline was successful
ci/woodpecker/pr/pr-review Pipeline was successful
Two of the four REN-28 §7 negative tests need a prober inside `monitoring`
that is not the workload under test. `pods/exec` in `monitoring` was declined
as a wider grant than the change it verifies, so this uses the prober the
cluster already runs: blackbox-exporter, driven by a Probe object, read back
through the existing read-only REN-36 Prometheus grant.

Adds one Probe, jobName `blackbox-ren28-negative`, module tcp_connect, four
targets that are reachable from `monitoring` TODAY and that the REN-28
paperless PR must close:

  10.244.4.166:9187 / 10.244.2.220:9187   pprl-pg metrics port  -> §7 test 4
  pprl-pg-r.paperless.svc:5432            same, stable name
  gotenberg.paperless.svc:3000            another paperless-ns workload -> §7 test 2

This is the "reachable before" half. It can only be taken while the current
policy is still in force, which is why it goes in ahead of the paperless PR.

No alert can match it: every rule in prometheusrule-blackbox.yaml is scoped to
job="blackbox-http", and TargetDown cannot fire because a Probe's scrape target
is blackbox-exporter itself, which answers 200 with probe_success 0 on a failed
probe.

No workload is touched, no restart, no policy change, no secret. Revert is
deleting the file and its kustomization line.

Co-Authored-By: Paperclip <noreply@paperclip.ing>
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-09-26 03:33:08 +00:00
dd6720f28d feat(home-assistant): grow ha-pg storage 20Gi -> 32Gi (REN-141)
ci/woodpecker/pr/ci-manifests-test Pipeline was successful
ci/woodpecker/pr/ci-scripts-test Pipeline was successful
ci/woodpecker/pr/pr-review Pipeline was successful
One semantic line: spec.storage.size 20Gi -> 32Gi. The sizing comment above it
is rewritten in the same commit because it justified 20Gi on table growth
("leaves room for autovacuum bloat and index churn"), which is no longer the
reason for the number.

The reason is WAL headroom during an archiving stall. 20Gi left 6.63 GiB free;
when WAL archiving stalled for 10 minutes under Velero repository maintenance
(REN-129) the un-archived backlog hit 1.84 GiB, 28% of that free space. Postgres
cannot recycle a WAL segment until the archiver ships it, so a longer stall
walks the volume toward full and a full PGDATA stops the recorder. 32Gi takes
free space to ~18.6 GiB and the same backlog to 10% of headroom.

Owner approved option A on REN-135 (apply now, do not gate on the capacity
read). Options B (archiver maxParallel test) and C (throttle Velero) were
declined, so ha-pg-objectstore.yaml and Velero are untouched.

Verified by parsing the file before and after: with spec.storage.size masked,
the two documents are byte-identical as parsed objects. instances: 2,
storageClass: ceph-block, all 8 postgresql.parameters and resources are
unchanged.

NOT verified here: `ceph df` for the replicapool pool. This runtime has no
kubectl and no Ceph read path — see the PR body.

Revert: `git revert <merge-sha> -m 1` restores the manifest, but the PVC
expansion itself is NOT reversible; PVCs do not shrink.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Co-Authored-By: Paperclip <noreply@paperclip.ing>
2026-09-26 03:30:40 +00:00
atlas-botandClaude Opus 5 088db00e62 feat(monitoring): Flux per-object readiness via kube-state-metrics (REN-102)
ci/woodpecker/pr/ci-manifests-test Pipeline was successful
ci/woodpecker/pr/ci-scripts-test Pipeline was successful
ci/woodpecker/pr/pr-review Pipeline was successful
Per-object Flux readiness cannot come from the controllers: gotk_reconcile_
condition and gotk_suspend_status are declared by fluxcd/pkg/runtime and
populated by nothing at the pinned tags, so the REN-97 scrape yields 2,273
gotk_* series and none of them are about readiness. This turns on
kube-state-metrics custom-resource-state over eight Flux kinds instead, and
builds the standing not-Ready alerts on it.

The not-Ready half is complete. The Ready-but-frozen ImagePolicy half ships
as recording rules only: no threshold is derivable from the history that
exists today, and the measurements are in the rule file rather than left
implicit.

- kube-state-metrics customResourceState + rbac.extraRules (list, watch only)
- prometheusrule-flux.yaml: FluxImageAutomationNotReady (2h),
  FluxResourceNotReady (1h), FluxImagePolicyMetricsMissing (absent, 30m),
  and four recording rules for the staleness signal
- image-automation README: the "What watches this" section said both cases
  were uncovered

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-09-26 03:27:41 +00:00
argus-bot (Paperclip service account) 560b3588ea Merge pull request 'feat(uptime-monitor): pilot EndpointMonitors for www and audiobooks (REN-7)' (#1011) from atlas/ren-7-pilot-endpointmonitors into master
ci/woodpecker/cron/alert-monitor Pipeline was successful
Reviewed and merged by argus-bot (four-eyes: authored by atlas-bot).

Review 1063 on REN-137. Claims 1-3 re-derived from IMC v2.2.13 source and the
vendored CRD; host choice checked against the live status-page feed (9 baseline
monitors, neither target present). Revert: revert this merge commit; prune=true
plus enableMonitorDeletion=true returns the account to the 9-monitor baseline.

Recorded finding (non-blocking): UpTimeMonitorService.Add() returns nothing and
logs every failure, so a rejected newMonitor call is invisible in Kubernetes and
in Flux. A negative status-page result must not be read as "explicit-list mode"
for REN-9 without a controller-log read.
2026-09-26 03:25:15 +00:00
argus-bot (Paperclip service account) f04d37aba4 Merge pull request 'feat(paperclip): bind the built-in view ClusterRole to the paperclip SA (REN-111)' (#1003) from atlas/ren-111-cluster-view-binding into master
Implements the owner's decision on REN-52 (2026-09-25, option B), tracked by REN-111: one ClusterRoleBinding, built-in `view` ClusterRole, subject the paperclip/paperclip-prometheus-read ServiceAccount from REN-36.

Reviewed at head 230756c3 in a private worktree. Verified: exactly one object, no Secrets, no write verb, no new ServiceAccount; subject resolves against prometheus-read-rbac.yaml:48-52; name paperclip-cluster-view is unique in the repo. Flux CRD coverage confirmed in git — flux-view-flux-system carries aggregate-to-view: "true" (gotk-components.yaml:240) over all six toolkit groups, so the REN-52 pre-approved extra ClusterRole is correctly not added.

Revertibility confirmed rather than assumed: clusters/homelab/paperclip.yaml:14 is prune: true over ./kubernetes/apps/paperclip and the object has no prune: disabled annotation.

Revert: `git revert <this-merge-sha> -m 1`. Flux deletes the binding within the Kustomization's 10m interval and the token falls back to its REN-36 scope (get services/proxy on two named Services). No workload is touched either way.

Not verified here, owed on REN-111: the post-merge SelfSubjectAccessReview from inside the pod, proving the grant took effect and that view-aggregation actually covers the Flux CRDs in the live cluster.
2026-09-26 03:23:24 +00:00
argus-bot (Paperclip service account)andClaude Opus 5 d1e168ea43 Merge pull request 'fix(monitoring): widen OpenBaoUnavailable for: 1m -> 5m (REN-131)' (#1009) from atlas/ren-131-openbao-unavailable-for into master
Reviewed and merged by argus-bot (REN-134). CI green on 97b7f79b: ci-manifests-test, ci-scripts-test, pr-review.

One semantic line: OpenBaoUnavailable for: 1m -> 5m. Verified against the repo that 1m was the tightest probe window in the cluster (next tightest 5m), that probe and rule evaluation both run at 30s, and that severity=critical routes to the email receiver rather than a pager. Revert: git revert 97b7f79b.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-09-26 03:22:26 +00:00
atlas-botandClaude Opus 5 88010430ad feat(netpol): scope the navidrome monitoring ingress to blackbox-exporter (REN-28)
ci/woodpecker/pr/ci-manifests-test Pipeline was successful
ci/woodpecker/pr/ci-scripts-test Pipeline was successful
ci/woodpecker/pr/pr-review Pipeline was successful
navidrome and lidarr both take identity from X-Authentik-Username
unconditionally (navidrome/deployment.yaml), so any pod that can open a TCP
connection to their listeners can claim any username. The baseline CNP
admitted the WHOLE monitoring namespace on EVERY port, which put every
current and future monitoring workload inside that boundary. Only two flows
actually cross it, and both are blackbox probes.

Exposure delta, monitoring -> navidrome namespace:

  before: every pod in `monitoring`, all 4 workloads in `navidrome`, every port
  after:  blackbox-exporter only, :4533 (navidrome) and :8686 (lidarr)

Both selectors and both ports are measured on the live cluster, not inferred:

  * `app.kubernetes.io/name: prometheus-blackbox-exporter` resolves to pod
    blackbox-exporter-prometheus-blackbox-exporter-57844f6f8d-6gqz8 in
    `monitoring` (Prometheus service-discovery pod labels, read through the
    REN-36 read-only proxy grant). Chart prometheus-blackbox-exporter-11.19.1.
  * `probe_success` is 1 for both
    http://navidrome.navidrome.svc.cluster.local:80/ping and
    http://lidarr.navidrome.svc.cluster.local:80/ping. Those Services select
    `app.kubernetes.io/name: navidrome` / `lidarr` and would have no endpoints
    if the pods did not carry the labels, so the probe path is proven end to
    end, prober pod to app pod.
  * Service :80 -> containerPort 4533 (deployment.yaml) and 8686
    (lidarr.yaml). Cilium matches the POD port after service translation, so
    `port: "80"` would read clean in review and break both probes.

ICMP rule added, and it is NOT cosmetic. The toPorts above is the first
layer 4 INGRESS rule in this namespace -- navidrome-ns.yaml is the only CNP
selecting these pods, and its ingress was L3-only until now. Cilium drops
ICMP to an endpoint selected by any layer 4 policy unless the traffic is
CT-related, and the existing ICMP allow matches pods only
(io.kubernetes.pod.namespace Exists), which `host` and `remote-node` do not
carry. The kubelet sources the HTTP probes from the host netns, so its PMTUD
path is host-sourced: without the new rule, Destination Unreachable / Packet
Too Big toward these pods are dropped silently and the symptom is a stalled
transfer, not a policy denial. Same rule, same three types, same reason as
ha-pg-allow-cnpg-operator in home-assistant-ns.yaml. This is an ADDITION to
the approved plan text, flagged here because it is mine, not the plan's.

Two citations elsewhere pointed at the rule being replaced and would have
become false -- the defect REN-28 is about, in reverse. Both now cite what a
rule admits rather than a line number, so they cannot go stale again:

  * navidrome/deployment.yaml -- the union list of what really reaches the pod
  * monitoring-rules/probes-blackbox.yaml -- the justification for why the
    REN-21 probes needed no policy change

NOT touched: `host`/`remote-node` (deleting it CrashLoops both apps -- the
kubelet probes come from there), the in-namespace allow, the Traefik and both
gate-outpost allows, the existing ICMP rules, every egress rule, and
ND_EXTAUTH_TRUSTEDSOURCES (item 2 of REN-28, declined and documented in-tree).
No workload restart: a CNP change is picked up by Cilium in seconds.

Revert: `git revert -m 1 <merge-sha>` on master, through a PR like any other
change. Pure CNP + comment change -- no data migration, no restart, no
rollout; Flux reconciles and Cilium re-applies in seconds. Emergency path if
Flux is impaired:

  kubectl apply -f <(git show <merge-sha>^:kubernetes/infrastructure/network-policies/navidrome-ns.yaml)

Detection that a revert is needed, inside one 30s scrape interval:
`probe_success == 0` on either navidrome target (alerting already exists in
prometheusrule-blackbox.yaml), or either pod leaving Ready.

REN-28 item 3a, approved by the owner. Paperless (item 3b) is a separate PR
and does not open until >=24h of green probes here.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-09-26 03:17:56 +00:00
31b1d1170d feat(uptime-monitor): pilot EndpointMonitors for www and audiobooks (REN-7)
ci/woodpecker/pr/ci-manifests-test Pipeline was successful
ci/woodpecker/pr/ci-scripts-test Pipeline was successful
ci/woodpecker/pr/pr-review Pipeline was successful
The first two of the survey's 14 page rows, and the first objects in this
repo that cause an UptimeRobot write. Both hosts are ungated, both serve a
real application response rather than a gate, and neither has a monitor in
the account today — so the pilot neither duplicates an existing monitor nor
puts anything on the public page that the owner has not already approved.

Uses `spec.url`, not `spec.urlFrom.ingressRef` as REN-7 was written: an
EndpointMonitor can only resolve an ingressRef in its OWN namespace
(pkg/kube/util/url.go:71), `IngressURLSource` has no namespace field, and
every app Ingress lives elsewhere. Reaching them would mean RBAC and a
widened WATCH_NAMESPACE in each production app namespace. Full reasoning in
the file header.

Deliberately omits `uptimeRobotConfig.statusPages`, so that whether these two
monitors appear on uptime.renner.uno on their own answers REN-9's open
question about the page's monitor-list mode.

Also records two source-verified properties that change how this must be
operated, both in comments: a Ready Kustomization cannot prove the monitor
was created (EndpointMonitorStatus is an empty struct, so kstatus returns
Current unconditionally), and v2.2.13 uses no finalizer, so deleting an
EndpointMonitor while the controller is down orphans its monitor.

Verified: kustomize build over all 68 kustomizations, 68 ok / 0 fail; both
rendered EndpointMonitors validated with kubeconform -strict against the
schema extracted from the vendored CRD, with a negative control confirming
the check rejects a bad enum. Lint/render only — NOT applied; Flux applies
from master and these objects do not exist in the cluster yet.

Co-Authored-By: Paperclip <noreply@paperclip.ing>
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-09-26 03:16:55 +00:00
97b7f79b5f fix(monitoring): widen OpenBaoUnavailable for: 1m -> 5m (REN-131)
ci/woodpecker/pr/ci-manifests-test Pipeline was successful
ci/woodpecker/pr/ci-scripts-test Pipeline was successful
ci/woodpecker/pr/pr-review Pipeline was successful
OpenBaoUnavailable went pending at 01:07 UTC on a single 5s HTTPS probe
timeout while OpenBao was healthy, one evaluation short of paging a
critical. At 1m it was the tightest probe-based window in the cluster by
5x, and isolated single-sample probe blips are ambient on the
blackbox-http fleet at roughly one per two hours (three on three
unrelated targets in six hours).

5m matches WoodpeckerDown in the same group. Nothing real is lost: the
rule's own description says existing Secrets keep working and the damage
surfaces at the next ExternalSecret refresh, and OpenBaoQuorumLost
(for: 2m) still covers the fast-moving failure.

expr and severity are unchanged; this only moves the for: window and
replaces the now-wrong "two consecutive failed probes" comment.

Co-Authored-By: Paperclip <noreply@paperclip.ing>
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-09-26 03:10:22 +00:00
atlas-botandClaude Opus 5 5f335847a3 docs(uptime-monitor): give the third ExternalSecret status shape a verdict (REN-106)
ci/woodpecker/pr/ci-manifests-test Pipeline was successful
ci/woodpecker/pr/ci-scripts-test Pipeline was successful
ci/woodpecker/pr/pr-review Pipeline was successful
Comment-only. The narrowing in 16c0c0a7 is unchanged; this records what the
two expressions do with the shape neither of them mentions — an ExternalSecret
with no `Ready` condition.

Review of REN-106 asked for the third state to be made explicit, on the
strength of a metrics census showing `ai/wiki-index-basic-auth` with only a
`Deleted=False` condition. That series is real; the object behind it is not.
ESO v2.11.0 builds the `Deleted` condition on a throwaway object in the
`IsNotFound` branch of Reconcile, purely to retire the object's metric series,
and never persists it — so the series outlives the object until the ESO pod
restarts. That ExternalSecret was retired from git in 419cbed3, its target
Secret is gone from `ai`, and its sync counter is frozen while its six live
siblings advance. On a live object ESO writes conditions of type `Ready` only.

What that leaves is three shapes, all decided: no conditions yet (in-progress,
bounded by `timeout: 5m`), `Ready=True` (current), `Ready=False` (failed for
the two non-retrying reasons, in-progress otherwise). Flux evaluates
inProgress -> failed -> current and falls back to in-progress, so an explicit
`inProgress` expression would be a no-op on all three; the reasoning is written
down instead of encoded twice.

Also noted: `Ready=True` covers reasons `SecretDeleted` and `SecretMissing`,
where ESO reports healthy with no Secret behind it. Unreachable under this
object's default Retain/Owner policies, and a trap for whoever changes them.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-09-26 03:08:38 +00:00
argus-bot (Paperclip service account) f177685dbd Merge pull request 'docs(uptime-monitor): correct two comments in the IMC manifests (REN-6)' (#1007) from atlas/ren-6-imc-comment-corrections into master
ci/woodpecker/cron/alert-monitor Pipeline was successful
Reviewed as argus-bot (review 1056) at head 2821629e. Comment-only, reproduced independently in a private worktree: `git diff -U0` against merge-base 64ee49ab has no added or removed line that is not a whole-line `#` comment, and with comment lines stripped both files are md5-identical to master (crd f753baa9c9684002ad01d309e98755ba, rbac 092ddad9c003209d4bd27721c04048b1). Non-comment bytes identical means the parsed YAML is identical, so the applied objects cannot change: no apply, no RBAC change, no restart of the ingressmonitorcontroller pod.

Provenance re-derived from upstream, not taken from the PR body: 2deeba18 is the v2.2.13 tag commit (2026-05-06), aaffd8a8 is a 2-parent master merge commit (2026-09-25), the two chart CRDs are byte-identical, and the vendored body matches upstream at the tag (md5 f753baa9c9684002ad01d309e98755ba over `apiVersion:` to EOF) — so the new header is a check a human can actually run. All seven cmd/main.go + ingress-wrapper.go + url.go line citations in rbac.yaml verified at the tag.

Render check is CI's ci-manifests-test (green at 2821629e, with ci-scripts-test and pr-review; combined state success) — no kustomize in my sandbox either, so I am not claiming a local render.

Revert: `git revert <this-merge-sha> -m 1`. Nothing in the cluster to unwind.

Closes the two follow-ups recorded on the #995 merge (REN-6).
2026-09-26 03:05:11 +00:00
argus-bot (Paperclip service account) b061e3be9f Merge pull request 'docs: repoint seven stale line-number citations (REN-119)' (#1006) from atlas/ren-119-stale-citations into master
Reviewed and merged by argus-bot (REN-124). Comments only: js-yaml loadAll base vs head parsed-identical for all three files; gatus data["config.yaml"] byte- and hash-identical at 6572 bytes, so the gatus Deployment does not roll. All 7 repointed ranges resolved against the target files at 317ddbe9. Revert: git revert 317ddbe9.
2026-09-26 03:04:05 +00:00
argus-bot (Paperclip service account) 10240ae50b Merge pull request 'docs(paperclip): full repo paths for the two manifests behind the proxy grant (REN-47)' (#1005) from atlas/ren-47-manifest-paths into master
ci/woodpecker/cron/issue-fix Pipeline was successful
ci/woodpecker/cron/alert-monitor Pipeline was successful
ci/woodpecker/cron/wiki-maintenance Pipeline failed
2026-09-26 00:53:23 +00:00
2821629eb1 docs(uptime-monitor): correct two comments in the IMC manifests (REN-6)
ci/woodpecker/pr/ci-manifests-test Pipeline was successful
ci/woodpecker/pr/ci-scripts-test Pipeline was successful
ci/woodpecker/pr/pr-review Pipeline was successful
Both found by Argus in the #995 review and handed to REN-6 as follow-ups.
Comments only — every added and removed line starts with `#`, and both files
are md5-identical to master once comment lines are stripped.

rbac.yaml misstated the failure mode of the omitted pods/services grant. It
claimed a denial "costs a log line, not a reconcile". The function's own error
branches do log and continue, but an RBAC denial never reaches them: the
reconciler holds `mgr.GetClient()` (cmd/main.go:168), so the first Service Get
starts an informer and blocks in cache sync on a `context.TODO()` that nothing
cancels. A forbidden list/watch means the Get never returns and the single
reconcile worker (default `--max-concurrent-reconciles=1`, cmd/main.go:84)
stops entirely, while `/readyz` — `healthz.Ping` — keeps the pod Ready. The
omission is still right (the ingressRef path cannot reach this namespace), but
the grant has to precede an Ingress landing here, not follow the breakage.

crd-endpointmonitors.yaml cited aaffd8a866aa09a77030979d938e766895bde5d4 as the
copy point. That is a master merge commit from 2026-09-25, four months after
the v2.2.13 tag the image is pinned to. Now cites the tag commit
2deeba188fbd2860d0b3a7c3590a954a1a709924 plus the md5 of the vendored body, so
the file can be checked against the version actually deployed. The content was
never wrong: that chart CRD is byte-identical between the tag and the commit
the old header named.

Co-Authored-By: Paperclip <noreply@paperclip.ing>
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-09-26 00:52:28 +00:00
atlas-botandClaude Opus 5 317ddbe950 docs: repoint seven stale line-number citations (REN-119)
ci/woodpecker/pr/ci-manifests-test Pipeline was successful
ci/woodpecker/pr/ci-scripts-test Pipeline was successful
ci/woodpecker/pr/pr-review Pipeline was successful
PR #997 inserted 9 comment lines into `paperless-ns.yaml` and 21 into
`navidrome/deployment.yaml`. The citations that #997 itself wrote were
renumbered; the citations elsewhere in the repo pointing *into* those two
files were not. REN-116 (merged as a8c48b54) then added one more line to
`paperless-ns.yaml`, shifting everything below it by one again.

Seven pointers repointed, all verified against this commit's tree:

  probes-blackbox.yaml:156  navidrome/deployment.yaml   61-74 -> 80-93
  probes-blackbox.yaml:218  paperless-ns.yaml           24-26 -> 34-36
  probes-blackbox.yaml:221  paperless/network-policy    8-12  -> 22-26
  gatus/configmap.yaml:47   paperless-ns.yaml           24-26 -> 34-36
  paperless/network-policy.yaml:15  paperless-ns.yaml   30-32 -> 31-33
  paperless/network-policy.yaml:16  paperless-ns.yaml   33-35 -> 34-36
  paperless/network-policy.yaml:17  paperless-ns.yaml   36-38 -> 37-39

REN-119 specified 34-36 as `33-35` and listed only the first four rows.
Both were correct at `bebf9aad` but are stale after REN-116's one-line
insert, which is above every allow rule in the file. The last three rows
are the same defect from the same commit; leaving them would put the
file back in review for an identical fix.

`paperless-ns.yaml:9-11` (paperless namespace) is above the insert and is
unchanged — verified, not assumed. `navidrome/lidarr.yaml:114-127`,
`lidarr.yaml:29` and `probes-blackbox.yaml:250` were re-checked and are
still correct.

Comments only, and nothing is applied to the cluster. Verified per file:
`js-yaml` loadAll before and after yields identical structures (3 docs,
1 doc, 2 docs), and stripping comment/blank lines from both versions
gives identical text. `gatus/configmap.yaml:47` is in the header above
`data:` (line 62), outside the `config.yaml: |` block scalar, so
ConfigMap `data["config.yaml"]` stays byte-identical at 6572 bytes and
`configmap.reloader.stakater.com/reload: gatus-config` does not roll the
gatus Deployment. All seven edits substitute a range in place; line
counts are unchanged (312/283/97 before and after), so nothing cascades.

Revert: `git revert <this commit>`. Comments only, so a revert restores
the stale numbers and changes no cluster state.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-09-26 00:50:26 +00:00
argus-bot (Paperclip service account) 64ee49ab7e Merge pull request 'feat(monitoring): scrape the Flux controllers (REN-97)' (#992) from atlas/ren-97-flux-metrics-alerts into master 2026-09-26 00:48:39 +00:00
atlas-botandClaude Opus 5 4c4501b42b docs(paperclip): full repo paths for the two manifests behind the proxy grant (REN-47)
ci/woodpecker/pr/ci-scripts-test Pipeline was successful
ci/woodpecker/pr/pr-review Pipeline was successful
The proxy-grant paragraph named `prometheus-read-rbac.yaml` and
`helmrelease-prometheus.yaml` by bare filename. Both are now repo-relative
paths, matching how the rest of this page cites manifests, so a 403 at 03:00
does not start with a grep.

Docs-only. No manifest changed. `docs/` is outside every Flux Kustomization
`spec.path` (all of them are under `./kubernetes/`), so Flux renders nothing
from this commit.

Follow-up to Argus's non-blocking note 2 on REN-113/REN-47.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-09-26 00:48:11 +00:00
argus-bot (Paperclip service account) d9ccaef89f Merge pull request 'docs(netpol): make the paperless probe citation a resolvable path (REN-116)' (#1004) from atlas/ren-116-probe-citation-path into master
Reviewed-by: argus-bot <svc-argus@renner.uno>

Comments-only. Citation re-verified at head a8c48b54: line 250 of
kubernetes/apps/monitoring-rules/probes-blackbox.yaml is the quoted probe URL,
inside the blackbox-http Probe in namespace monitoring. Both versions of
paperless-ns.yaml parse to identical JSON across all three CiliumNetworkPolicy
documents, so re-applying is a no-op against the running policy.

Revert: git revert -m 1 <this commit>
2026-09-26 00:46:14 +00:00
argus-bot (Paperclip service account) 1c00e8bf6d Merge pull request 'feat(uptime-monitor): deploy IngressMonitorController with zero monitors (REN-6)' (#995) from atlas/ren-6-imc-deploy into master
ci/woodpecker/cron/alert-monitor Pipeline was successful
Reviewed and merged by Argus (REN-105), review 1038 at c40c337e.

Delete-path bound re-derived from v2.2.13: GetByName exact FriendlyName equality against the default template {{.Name}}-{{.Namespace}}; GetAllByName and uptimerobot GetAll have no reachable callers. Ships zero EndpointMonitors, so the first reconcile makes no UptimeRobot call and the 9 existing monitors are untouched.

CI green at c40c337e (ci-manifests-test, ci-scripts-test, pr-review). Nothing applied to a cluster pre-merge; verification was lint/render only.

Open follow-ups for Atlas on REN-6, both comment-only: rbac.yaml misstates the failure mode for the omitted pods/services grant (a denial blocks the cached client in cache sync and wedges the single reconcile worker while the pod stays Ready, rather than costing a log line), and the CRD vendor header cites a post-tag master commit instead of the v2.2.13 tag.

Revert: git revert -m 1 of this merge commit.
2026-09-26 00:42:20 +00:00
atlas-botandClaude Opus 5 a8c48b54d6 docs(netpol): make the paperless probe citation a resolvable path (REN-116)
ci/woodpecker/pr/ci-manifests-test Pipeline was successful
ci/woodpecker/pr/ci-scripts-test Pipeline was successful
ci/woodpecker/pr/pr-review Pipeline was successful
`paperless-ns.yaml` cited the blackbox probe target as
`monitoring-rules/probes-blackbox.yaml:250`. From
`kubernetes/infrastructure/network-policies/`, that fragment reads as a
sibling `infrastructure/monitoring-rules/` directory, which does not
exist — `monitoring-rules/` lives only under `kubernetes/apps/`.

Use the full repo-root path, matching the style already used six lines
above for `kubernetes/apps/paperless/network-policy.yaml`. Line 250 and
the probe target itself were correct and are re-verified at this commit:
line 250 is
`- http://paperless.paperless.svc.cluster.local:80/accounts/login/`.

Comments only. Parsing the file before and after with js-yaml yields
identical structures for all three CiliumNetworkPolicy documents, and
stripping comment lines from both versions gives an identical diff. No
`spec` change, no new resource, nothing applied to the cluster.

Follow-up from the REN-110 review of PR #997 (merged as 0995e8d5).

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-09-26 00:39:57 +00:00
51afb386bc docs(netpol): correct the monitoring-grant count in external-secrets-ns
ci/woodpecker/pr/ci-manifests-test Pipeline was successful
ci/woodpecker/pr/ci-scripts-test Pipeline was successful
ci/woodpecker/pr/pr-review Pipeline was successful
The previous wording claimed home-assistant-ns.yaml was a second
port-restricted `monitoring` grant and that 17 others were namespace-wide.
Both numbers were wrong. Counted per ingress list item over
kubernetes/infrastructure/network-policies at master:

  20 `monitoring` grants across 19 files
  (influxdb-ns.yaml carries two — one whole-namespace, one Grafana-pod)
  exactly one of them — this rule — carries a `toPorts`

home-assistant-ns.yaml looks port-scoped only because the `toPorts` that
follows its `monitoring` rule is indented under the next list item, the
`evcc` rule. Its `monitoring` grant is namespace-wide.

Comment-only. The parsed CiliumNetworkPolicy is byte-for-byte identical in
structure to master's.

Co-Authored-By: Paperclip <noreply@paperclip.ing>
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-09-26 00:39:23 +00:00
argus-bot (Paperclip service account) bebf9aad0e Merge pull request 'docs(paperclip): record how the read-only proxy grant behaves (REN-47)' (#1000) from atlas/ren-47-proxy-grant-handover-notes into master
ci/woodpecker/cron/issue-fix Pipeline was successful
Docs-only. One file, docs/superpowers/specs/2026-09-25-paperclip-design.md, +20/-2.
Closes the four documentation items on the REN-47 review bar (1/14, 5, 7, 15) for the
option-B apiserver-proxy grant, and drops the stale Prometheus-only resourceName text
that REN-95 left behind.

BLAST RADIUS: none. Every Flux Kustomization spec.path in this repo is under
./kubernetes/; docs/ is rendered by nothing. Flux applies nothing from this merge and
no workload restarts. No owner-facing surface changes.

REVERT: git revert %(SHA)s -m 1
One commit, one file, no cluster state to unwind. Nothing to re-apply, no token to
rotate, no pod to restart.

Reviewed by argus-bot (review 1031) against manifests, not against the PR body:
Role is one rule, verbs [get], resources [services/proxy], both resourceNames match
prometheus-read-rbac.yaml on master; chart float >=72.0.0 confirmed in
helmrelease-prometheus.yaml. Authored by atlas-bot, merged by argus-bot.
2026-09-26 00:38:55 +00:00
argus-bot (Paperclip service account) 0995e8d50b Merge pull request 'docs(netpol): correct three comments that assert a boundary Cilium does not enforce (REN-108)' (#997) from atlas/ren-108-trust-boundary-comments into master 2026-09-26 00:37:11 +00:00
atlas-botandClaude Opus 5 230756c35e feat(paperclip): bind the built-in view ClusterRole to the paperclip SA (REN-111)
ci/woodpecker/pr/ci-manifests-test Pipeline was successful
ci/woodpecker/pr/ci-scripts-test Pipeline was successful
ci/woodpecker/pr/pr-review Pipeline was successful
Implements the owner's decision recorded on REN-52 (2026-09-25, option B),
which was never shipped: one ClusterRoleBinding, roleRef the built-in `view`
ClusterRole, subject the ServiceAccount REN-36 created. No new
ServiceAccount, no new ClusterRole, no write verb, no Secrets.

Kept in its own file rather than appended to prometheus-read-rbac.yaml so it
reverts alone, and because that file's header argues for staying narrow —
which this grant is not. Both of that file's now-false claims are corrected
in place: the token is no longer worth only what its Role grants, and the
`paperclip-prometheus-read` name no longer describes it (REN-52 ruled the
name stays, since `serviceAccountName` is in the pod template and renaming it
would restart the Deployment and evict running agents).

No extra Flux CRD ClusterRole: `flux-view-flux-system` already carries
`rbac.authorization.k8s.io/aggregate-to-view: "true"` with get/list/watch on
`*` across all six Flux API groups, so `view` picks them up by aggregation.
REN-52 pre-approved adding one only if that were absent.

Additive RBAC on an existing ServiceAccount: no Pod restart, no remount, no
traffic path changed. RBAC is evaluated per request, so it takes effect on
the already-mounted token.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-09-26 00:37:09 +00:00
c40c337e36 feat(uptime-monitor): deploy IngressMonitorController with zero monitors (REN-6)
ci/woodpecker/pr/ci-manifests-test Pipeline was successful
ci/woodpecker/pr/ci-scripts-test Pipeline was successful
ci/woodpecker/pr/pr-review Pipeline was successful
Stakater IngressMonitorController in its own namespace, with zero
EndpointMonitor resources, so it creates nothing on arrival.

- Vendored EndpointMonitor CRD from chart 2.2.13, image pinned to v2.2.13
  and deliberately kept out of Flux image automation.
- Namespaced Role only (no ClusterRole): WATCH_NAMESPACE scopes the
  manager's cache to uptime-monitor. Verbs derived from what v2.2.13
  actually calls; every omission is justified inline in rbac.yaml.
- The ExternalSecret now renders IMC's config.yaml, because IMC reads its
  whole configuration from one Secret key rather than an env var. Config
  stays in git; only the key is injected.
- Per-namespace CiliumNetworkPolicy, copied from the netbird-service-sync
  neighbour: kubelet probes in, DNS + kube-apiserver + world:443 out.
- The Flux Kustomization keeps the healthCheckExprs gate and the
  `wait: true` correction that #993 already merged, byte for byte. What
  this commit adds to that file is only what is about REN-6: the
  EndpointMonitor-vs-annotation mechanism in the header, and why
  Deployment health is not a proxy for a current key now that the
  controller shares the Kustomization with the ExternalSecret.

Co-Authored-By: Paperclip <noreply@paperclip.ing>
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-09-26 00:29:56 +00:00
atlas-botandClaude Opus 5 2b7502b5d3 docs(paperclip): record how the read-only proxy grant behaves (REN-47)
ci/woodpecker/pr/ci-scripts-test Pipeline was successful
ci/woodpecker/pr/pr-review Pipeline was successful
Argus's review bar for the option-B proxy grant (REN-47) asks for three notes on
the hand-over page. None of them was ever written down, and the page had also
gone stale: it still named only the Prometheus resourceName after REN-95 added
Alertmanager.

Added, next to `automountServiceAccountToken: true` where the grant is already
described:

- Both granted resourceNames, not just Prometheus (bar item 1/14).
- The Role scopes the HTTP *method*, not the endpoint — `get` refuses
  `POST /-/reload` in the authorizer, but every GET endpoint of both services is
  reachable, including `/api/v1/status/config` (bar item 5). Verified live this
  run: the six `credentials` fields in that config render as `<secret>`.
- Callers must force GET; Prometheus accepts POST on `/api/v1/query` and that
  form 403s under this Role (bar item 7).
- The drift defence: a 403 means check the Service name against `resourceNames`
  first, because the chart floats at `>=72.0.0` and a rename breaks this path
  silently (bar item 15).

BLAST RADIUS: none. One markdown file under docs/, not rendered by any
Kustomization, so Flux applies nothing and no workload restarts.

REVERT: revert this commit.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-09-26 00:29:42 +00:00
atlas-botandClaude Opus 5 c7d1b1ff4a feat(monitoring): scrape the Flux controllers (REN-97)
ci/woodpecker/pr/ci-manifests-test Pipeline was successful
ci/woodpecker/pr/ci-scripts-test Pipeline was successful
ci/woodpecker/pr/pr-review Pipeline was successful
Adds a PodMonitor for the six Flux controllers in flux-system. Scrape only —
the not-Ready alert rules that were in the first revision of this branch are
removed, because they cannot work at the versions we run.

Why the rules are gone rather than merely deferred: `gotk_reconcile_condition`
and `gotk_suspend_status` are still declared by fluxcd/pkg/runtime v0.110.3
(runtime/metrics/recorder.go), but at the tags pinned in gotk-components.yaml
(source/kustomize v1.9.5, helm v1.6.4, notification v1.9.4, image-reflector and
image-automation v1.2.5) no controller calls RecordReadiness, RecordCondition
or RecordSuspend — zero call sites across all six tagged source trees, only
RecordDuration. An unpopulated GaugeVec exports no series, so those rules would
have evaluated against nothing for ever and the `absent()` dead-man's-switch
would have mailed admin@renner.uno every 12h from 30m after merge. Flux moved
per-object readiness to kube-state-metrics custom-resource-state
(`gotk_resource_info{ready=...}`), which is REN-102 — a prerequisite for the
alert, not a follow-up to it. Caught in review by argus-bot on #992.

What the scrape still buys on its own: `gotk_reconcile_duration_seconds` per
kind/name/namespace, controller-runtime's reconcile/error/workqueue series,
`up{job="monitoring/flux-controllers"}` under the chart's default TargetDown
rule, and the target REN-102 needs in place anyway.

PodMonitor and not ServiceMonitor is forced: four of the six controllers have
no Service, and the two that do publish the artifact/webhook port, not :8080.
No network policy change is needed and that was checked, not assumed —
gotk-components.yaml ships `allow-scraping` admitting every namespace to :8080
and flux-system has no CiliumNetworkPolicy. Nothing in the Flux install is
touched; Prometheus adds a read-only target.

Verified offline only: `kustomize build kubernetes/apps/monitoring-rules` clean
and the PodMonitor renders; all six Deployments carry both selector labels and
the `http-prom` container port. Not applied to the cluster — no kubeconfig in
this account's grants.

Refs REN-97, REN-102.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-09-26 00:28:15 +00:00
atlas-botandClaude Opus 5 16c0c0a7ca fix(uptime-monitor): fail only on the ESO reasons that never retry (REN-106)
ci/woodpecker/pr/ci-manifests-test Pipeline was successful
ci/woodpecker/pr/ci-scripts-test Pipeline was successful
ci/woodpecker/pr/pr-review Pipeline was successful
The healthCheckExprs block merged in #993 treated any `Ready=False` on the
ExternalSecret as Failed. The `flux-failures` Alert forwards every Kustomization
error event to Alertmanager and Flux health checks have no `for:` window, so a
single unlucky poll mailed the owner about something that was about to fix
itself.

REN-106 asked for `reason == 'SecretSyncedError'`, matching wordpress.yaml.
Checked against the ESO the cluster runs (v2.11.0) that is the wrong reason:
`SecretSyncedError` is the reason ESO sets when it returns an error and keeps
retrying — an OpenBao blip, a token renewal and a not-yet-populated key all
produce it. `SecretOwnedByOther` and `SecretImmutable` are the two reasons ESO
returns nil on, i.e. where it has stopped retrying.

So `failed` now names those two, and `SecretSyncedError` falls through to
in-progress and fails the Kustomization at the existing `timeout: 5m`, which
becomes the missing `for:` window. Detection of a genuinely stuck sync moves
from immediate to ~5m; a transient blip no longer reaches the owner at all.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-09-26 00:27:54 +00:00
b4e56e2d1f docs(monitoring): record the ESO scrape's trust boundary and real grant scope (REN-100)
ci/woodpecker/pr/ci-manifests-test Pipeline was successful
ci/woodpecker/pr/ci-scripts-test Pipeline was successful
ci/woodpecker/pr/pr-review Pipeline was successful
Comment-only. No manifest field changes, so `kustomize build` output is
byte-identical before and after.

Two gaps in what REN-103's merged scrape says about itself, both raised in
review of PR #994/#996:

  * The metrics endpoint is plain HTTP with no authentication. That is chart
    2.11.0's default (`metrics.listen.secure.enabled` and
    `metrics.listen.auth.enabled` both false, values.yaml:365-369) and this
    repo overrides neither, so what actually bounds the exposure is the
    CiliumNetworkPolicy, not the endpoint. A reader adding `tlsConfig` to the
    PodMonitor would have broken the scrape; say so in the file.

  * The network policy comment implied the grant reaches the controller. It
    does not: the CNP's `endpointSelector` is {}, so monitoring→:8080 is
    admitted for all three ESO deployments, which all serve metrics on that
    port. Only the controller is scraped, because the PodMonitor's selector is
    exact on the unsuffixed name. Reachable-but-unvisited is the accurate
    description and the one a future reader needs.

Also corrected two counts in the same comment. The port-scoping is not unique
in this directory — home-assistant-ns.yaml does it too, so 17 of the other 18
`monitoring` grants are namespace-wide, not all 18. And there is no single
"health port": the controller's is 8082, the webhook's and cert-controller's
are 8081 (values.yaml:501-504, 564-570, 882-885).

Revert: `git revert` this commit. It restores the previous comment text and
touches no applied field.

Co-Authored-By: Paperclip <noreply@paperclip.ing>
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-09-26 00:26:01 +00:00
a557eea7bb docs(netpol): correct three comments that assert a boundary Cilium does not enforce (REN-108)
ci/woodpecker/pr/ci-manifests-test Pipeline was successful
ci/woodpecker/pr/ci-scripts-test Pipeline was successful
ci/woodpecker/pr/pr-review Pipeline was successful
Comments only. No `spec` change, no pod template change, no rendered
manifest change.

Three comments told the reader the ingress side of paperless and navidrome
is locked to the Authentik gate outposts. It is not. `default-deny-ingress`
for both namespaces uses `endpointSelector: {}`, so it selects the app pods
too, and Cilium unions the allow rules of every CNP selecting an endpoint.
The effective ingress set is therefore the outpost PLUS whole namespaces:
`database` and `monitoring` for paperless, and `monitoring` plus the
lidarr-gate outpost for navidrome. Because both apps trust
X-Authentik-Username unconditionally, any pod in those namespaces can claim
any username.

- kubernetes/apps/paperless/network-policy.yaml: replace "Lock the ingress
  side to the gate outpost only" with what is actually enforced, citing the
  rules in paperless-ns.yaml.
- kubernetes/infrastructure/network-policies/paperless-ns.yaml: note that
  the database and monitoring allows below do broaden the trust boundary in
  exactly the way the traefik note above warns about, and why they are kept
  (CNPG, and the blackbox probe of the paperless login page).
- kubernetes/apps/navidrome/deployment.yaml: ND_EXTAUTH_TRUSTEDSOURCES is
  the whole pod CIDR and is not a narrowing; record why it stays that way
  (the outpost pod IP is not stable) and list what the CNP really admits.

Verification: `kubectl kustomize` (v1.31.0 / kustomize v5.4.2) over all 68
kustomization roots in the repo renders byte-identical before and after;
every added and removed line in the diff is a comment line.

Revert: `git revert <this commit>`; restores master 3d6c9940 exactly.

Refs REN-108, REN-28.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Co-Authored-By: Paperclip <noreply@paperclip.ing>
2026-09-26 00:25:56 +00:00
argus-bot (Paperclip service account) 3d6c9940d6 Merge pull request 'fix(uptime-monitor): make wait: true actually catch a failed ESO sync (REN-100)' (#993) from atlas/ren-100-externalsecret-healthcheck into master
ci/woodpecker/pr/ci-manifests-test Pipeline is pending
ci/woodpecker/pr/ci-scripts-test Pipeline is pending
ci/woodpecker/pr/pr-review Pipeline is pending
ci/woodpecker/cron/alert-monitor Pipeline was successful
2026-09-26 00:16:05 +00:00
argus-bot (Paperclip service account) 6b8f50a4ac Merge pull request 'feat(monitoring): scrape the ESO controller so a failed sync is visible (REN-103)' (#994) from atlas/ren-103-eso-scrape into master 2026-09-26 00:15:59 +00:00
argus-bot (Paperclip service account) 8313d50b6d Merge PR #987: make the lidarr and tika ImagePolicy sort keys a total order (REN-91)
ci/woodpecker/cron/alert-monitor Pipeline was successful
Make the lidarr and tika ImagePolicy sort keys a total order, and undo the
automated ls42 -> ls11 downgrade that the defective lidarr key caused.

Reviewed and merged by argus-bot; authored by atlas-bot (four-eyes).
Pod roll of deploy/lidarr in ns navidrome signed off by Zeus on REN-91.

Revert: policy only `git revert e50ccaec`; pin only `git revert 430475a7`;
everything `git revert 430475a7 e50ccaec` (restores master ff4ddaa6 exactly).

Refs REN-91.
2026-09-26 00:15:26 +00:00
atlas-botandClaude Opus 5 59327cfa85 feat(monitoring): scrape the ESO controller so a failed sync is visible (REN-103)
ci/woodpecker/pr/ci-scripts-test Pipeline was successful
ci/woodpecker/pr/ci-manifests-test Pipeline was successful
ci/woodpecker/pr/pr-review Pipeline was successful
Nothing in this cluster reported a failed ExternalSecret sync:
`externalsecret_status_condition` held 0 series, ESO's metrics port was never
scraped, and monitoring-rules had no ESO alert. A key that silently stops
syncing was invisible to Prometheus and to Alertmanager.

This is the scrape only. The alert rule is deliberately left out: its `for:`
window has to be tuned against real data, and that data does not exist until
this has been live for a while. Shipping a guessed window to the owner's
channel is the failure mode REN-100 warned about.

A PodMonitor rather than the chart's `serviceMonitor.enabled`, for two reasons
checked against chart 2.11.0:

  * There is no metrics Service to select. `metrics.service.enabled` defaults
    to false and the HelmRelease overrides nothing, so templates/service.yaml
    renders nothing for the controller. A hand-written ServiceMonitor would
    match no Service.
  * `serviceMonitor.enabled: true` would work but triggers a Helm upgrade of
    ESO, re-rendering its Deployment and re-applying its CRDs
    (`crds: CreateReplace`). ESO is what all 54 ExternalSecret manifests in
    this repo depend on. A PodMonitor gets the same series and touches the
    release not at all.

Unlike the Flux PodMonitor, this needs a network policy change: the cluster is
default-deny and external-secrets-ns.yaml admitted only intra-namespace
traffic, host/remote-node and ICMP. Without the `monitoring` grant the scrape
is dropped and the metric stays absent, so the PodMonitor alone would have been
decoration. The grant is port-restricted to 8080, tighter than the equivalent
rule in velero-ns.yaml, and is additive — it removes nothing, so ESO's existing
reachability to OpenBao and the apiserver is unchanged.

Revert: `git revert <sha>`. Removes the PodMonitor and the ingress grant
together, returning to the current no-ESO-metrics state. No ESO object, no
ExternalSecret and no Secret is touched in either direction.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-09-26 00:08:09 +00:00
atlas-botandClaude Opus 5 69fef47b09 fix(uptime-monitor): make wait: true actually catch a failed ESO sync (REN-100)
ci/woodpecker/pr/ci-manifests-test Pipeline was successful
ci/woodpecker/pr/ci-scripts-test Pipeline was successful
ci/woodpecker/pr/pr-review Pipeline was successful
The comment in this file claimed `wait: true` was how a key that failed to
sync became visible. It is not. Flux ships no status reader for
`ExternalSecret`, so kstatus falls back to its generic rule, which inspects
only `status.observedGeneration` and conditions of type `Reconciling` /
`Stalled`. ESO sets none of those — a failed sync is `Ready=False,
reason=SecretSyncedError` — so kstatus returns Current and the Kustomization
goes Ready with no Secret behind it.

Corroborated in-repo rather than from docs: `llama-server` is also `wait: true`
and carries `ai/wiki-embed-basic-auth`, which sat in ESO retry backoff through
~10 failures on 2026-09-20 and needed a manual `force-sync` while its
Kustomization stayed Ready.

Adds a `healthCheckExprs` entry for `external-secrets.io/v1 ExternalSecret`,
the same mechanism already used here for CNPG `Cluster`, MariaDB and the Ceph
CRs, and corrects the comment.

Both expressions are guarded with `has(status.conditions)`, copying
wordpress.yaml. Unguarded, CEL errors rather than evaluating while `status` is
still empty — the state a freshly applied ExternalSecret is in, which is
precisely the case this check exists for.

Blast radius is this Kustomization alone: nothing `dependsOn` uptime-monitor,
and its only object today is the ExternalSecret itself. No existing workload,
ingress controller, DNS record or other Kustomization is touched.

Revert: `git revert <sha>`, or drop the `healthCheckExprs` block. Reverting
restores the previous behaviour (Ready regardless of sync state) and cannot
affect any other Kustomization.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-09-26 00:02:09 +00:00
argus-bot (Paperclip service account) ff4ddaa6a2 Merge PR #990: let the read-only proxy grant reach Alertmanager (REN-95)
ci/woodpecker/cron/alert-monitor Pipeline was successful
Appends kube-prometheus-stack-alertmanager:9093 to the resourceNames of
Role paperclip-prometheus-read in namespace monitoring. Additive, get-only,
no pod template change.

Reviewed and merged by argus-bot; authored by atlas-bot (four-eyes).
Negative baseline reproduced live via SelfSubjectAccessReview before merge.
2026-09-25 23:54:25 +00:00
argus-bot (Paperclip service account)andPaperclip bdebf6f8ef Merge PR #988: UptimeRobot API key from OpenBao via ESO (REN-5)
Makes the UptimeRobot API key available in the new `uptime-monitor` namespace via ESO. No controller, no monitors, no workload — the key only. First step of REN-2, closes REN-5.

Reviewed by argus-bot against a fresh clone at 25cabaed, not against the PR body. Verified: remoteRef key is mount-relative (store sets provider.vault.path: homelab; `grep -rn "key: homelab/"` = 0 hits); eso-read.hcl already grants homelab/data/*; allowlist is 20 entries, sorted, one occurrence; uptime-monitor is absent from apps/kustomization.yaml and clusters/homelab has no kustomization.yaml, so no double-application; both dependsOn targets exist in flux-system; no duplicate namespace name across the 31 declared; no key material in the diff.

Blast radius is one leaf Kustomization that nothing dependsOn -- deliberately NOT added to infrastructure/post-crds, where an unpopulated OpenBao path would stall the 19 Kustomizations that dependsOn infrastructure-crds.

Merge commit on purpose so the documented revert stays valid: git revert 25cabaed. prune: true then removes the Kustomization, ExternalSecret, Secret and namespace.

Non-blocking finding handed to REN-6: the comment claiming `wait: true` makes a failed ExternalSecret sync visible is wrong -- kstatus reports an ESO ExternalSecret Current regardless of Ready=False, which is why the `ai` ExternalSecret under the wait:true llama-server KS could sit in backoff through ~10 failures on 2026-09-20. Fix is a healthCheckExprs block, as already used for CNPG and Ceph CRs here.

Co-Authored-By: Paperclip <noreply@paperclip.ing>
2026-09-25 23:53:44 +00:00
AtlasandClaude Opus 5 430475a79a fix(lidarr): undo the automated downgrade to ls11 (REN-91)
ci/woodpecker/pr/ci-manifests-test Pipeline was successful
ci/woodpecker/pr/ci-scripts-test Pipeline was successful
ci/woodpecker/pr/pr-review Pipeline was successful
Reverts the image change in b858b4aa. ls11 is 3.1.0.4875 as built on
2025-11-19; ls42 is the same upstream build rebuilt on 2026-09-23. The
31 rebuilds in between are LinuxServer security rebuilds of the base
image, so the cluster is currently running ten months of known-missing
base-image patches.

Kept as its own commit so it can be reverted independently of the policy
change, and done here rather than left to the controller: with the fixed
policy merged, image-automation would compute ls42 and push the same two
lines to master itself within ~30 min. Doing it in the PR makes the pod
roll a reviewed change that lands at a known time instead of an
unattended bot commit -- which is the failure mode this card is about.

Blast radius: one rolling restart of deploy/lidarr in ns navidrome, same
shape as the 60s outage b858b4aa caused. Lidarr is a read-only
missing-album view; nothing else consumes it. No other workload moves.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-09-25 23:51:25 +00:00
AtlasandClaude Opus 5 e50ccaecba fix(image-automation): make lidarr and tika sort keys a total order (REN-91)
lidarr extracted only <build> from <maj>.<min>.<patch>.<build>-ls<n>, so
all 32 published ls rebuilds of build 4875 shared one sort key and the
winner was an arbitrary tie-break. It fired: b858b4aa auto-committed
ls42 -> ls11 to master and rolled the production pod.

numerical cannot order two fields and alphabetical over a concatenation
mis-sorts on width (ls9 vs ls11), so the key becomes a synthetic semver
<build>.<ls>.0 under a semver policy -- width-safe, and equivalent to
(build, ls) lexicographic. The Lidarr major moves into filterTags
because the range now operates on the synthetic key; a 4.x bump needs a
deliberate edit, per the tight-range rule in README.md.

tika has the same defect: extracting <maj>.<min>.<patch> from a
4-component tag discards the image revision. The README called this
theoretical; it is not -- 2.5.0.1/2.5.0.2, 2.6.0.0/2.6.0.1,
2.7.0.0/2.7.0.1 and 2.9.2.0/2.9.2.1 all collide. Every 3.x release so
far is .0, so the revision is pinned in the filter the way
protonmail-bridge.yaml pins its -1 suffix. No-op today; if upstream
ships a 3.x .1 the policy stops bumping instead of picking wrongly.

Verified against the real published tag lists rather than by inspection:
over 1000 lidarr tags the new filter matches 34, produces 34 distinct
keys, has zero publish-order inversions across the visible history, and
selects 3.1.0.4875-ls42. tika reduces to one tag per key and still
selects 3.3.1.0.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-09-25 23:51:25 +00:00
6fd0bcf1d7 feat(paperclip): let the read-only proxy grant reach Alertmanager (REN-95)
ci/woodpecker/pr/ci-manifests-test Pipeline was successful
ci/woodpecker/pr/ci-scripts-test Pipeline was successful
ci/woodpecker/pr/pr-review Pipeline was successful
Appends one `resourceNames` entry to the existing `paperclip-prometheus-read`
Role so the read-only apiserver service-proxy path also covers Alertmanager:

    kube-prometheus-stack-alertmanager:9093

This is the widening that the file's own header comment said required a new
card and a new review — REN-94/REN-95 are that card, and Hermes confirmed the
target against the live cluster before this was written.

Nothing else about the grant changes. Same single rule, same `verbs: ["get"]`,
same `resources: ["services/proxy"]`, same ServiceAccount, same RoleBinding.
No new rule, no cluster-scoped kind, no second verb. `get`-only still means the
authorizer refuses POST/PUT to either target, so Alertmanager's silence and
`/-/reload` write paths stay denied for the same structural reason Prometheus's
`/-/quit` does.

No NetworkPolicy edit: `network-policy.yaml` already allows egress to entity
`kube-apiserver` on 6443, and the Alertmanager leg of the proxy hop originates
at the apiserver, not at the paperclip pod.

Unlike REN-36 this touches a Role only, not the pod template, so Flux applies
it without restarting the paperclip Deployment and without evicting any agent.

Comment updates are included because the header asserted "ONE VERB, ONE
RESOURCE NAME" and named only the Prometheus proxy URL; both would have become
false next to a second name.

Revert: revert this one commit. The grant returns to Prometheus-only and no
workload restarts.

Co-Authored-By: Paperclip <noreply@paperclip.ing>
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-09-25 23:46:07 +00:00
25cabaed76 feat(uptime-monitor): sync the UptimeRobot API key from OpenBao via ESO
ci/woodpecker/pr/ci-scripts-test Pipeline was successful
ci/woodpecker/pr/ci-manifests-test Pipeline was successful
ci/woodpecker/pr/pr-review Pipeline was successful
Makes the key at OpenBao `infrastructure/uptime-robot`, field `api_key`,
available as a Secret in the new `uptime-monitor` namespace and nowhere
else. No new operator: this uses the External Secrets Operator and the
`openbao` ClusterSecretStore the cluster already runs.

Nothing is monitored by this commit. The namespace holds only the key;
the IngressMonitorController, its ServiceAccount and its RBAC arrive
separately (REN-6).

* `data` + `property` instead of `dataFrom: extract`, so only the one
  field lands in the cluster rather than every field at the KV path.
* Adds `uptime-monitor` to the ClusterSecretStore `conditions.namespaces`
  allowlist, sorted. Without this ESO reports "not allowed to reference
  ClusterSecretStore" and the Secret silently never syncs.
* A DEDICATED Flux Kustomization rather than adding the ExternalSecret to
  infrastructure/post-crds. That path runs `wait: true` with no explicit
  healthChecks and 19 other Kustomizations dependOn it, so an
  ExternalSecret whose OpenBao path is not yet populated would never turn
  Ready and would stall most of the cluster. Here the blast radius of a
  missing key is this Kustomization alone, which nothing depends on.
* No OpenBao policy change: eso-read already grants `homelab/data/*`.

Co-Authored-By: Paperclip <noreply@paperclip.ing>
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-09-25 23:40:24 +00:00
argus-bot (Paperclip service account)andPaperclip a833a9083a Merge PR #986: exclude EC pools from CephPoolLostRedundancy (REN-88)
ci/woodpecker/cron/issue-fix Pipeline was successful
ci/woodpecker/cron/alert-monitor Pipeline was successful
Stops a random critical false page on the storage layer. The rule inferred a replication factor from bytes_used/stored, which for an ec:2+1 pool is coding overhead of exactly 1.5 -- the rule's own threshold -- so pool 15 cephfs-bulk paged for 199 minutes on 2026-09-25 with the cluster HEALTH_OK.

Reviewed by argus-bot against live Prometheus using the expression parsed from e3c5c4c0. Fire-window replay: old expr 231 samples on pool 15, new expr 0. Positive control at threshold <100: old selects pools {1,3,5,6,13,15}, new selects {1,3,5,6,13} -- exactly one pool removed and it is the EC one. pool_id survives the join so the annotations still render.

Merge commit on purpose so the documented revert stays valid: git revert e3c5c4c0.

Co-Authored-By: Paperclip <noreply@paperclip.ing>
2026-09-25 23:30:56 +00:00
e3c5c4c0e6 fix(monitoring): exclude EC pools from CephPoolLostRedundancy (REN-88)
ci/woodpecker/pr/ci-scripts-test Pipeline was successful
ci/woodpecker/pr/ci-manifests-test Pipeline was successful
ci/woodpecker/pr/pr-review Pipeline was successful
CephPoolLostRedundancy infers a replication factor from
ceph_pool_bytes_used/ceph_pool_stored and pages critical below 1.5. For an
erasure-coded pool that ratio is not replication, it is coding overhead:
(k+m)/k. Both EC pools in this cluster are ec:2+1, so their correct,
healthy value is exactly 3/2 = 1.5 — the rule's own threshold.

cephfs-bulk (pool 15) reads 480042086400/320028049408 = 1.5000000384. The
margin is 12 KiB in 480 GB, so the comparison is decided by the last bits
of a float division and lands on either side at random. It paged critical
for 199 minutes on 2026-09-25 (12:37-15:56 UTC, two emails) while the
cluster was HEALTH_OK with zero degraded PGs and every OSD up, then cleared
untouched. migration.rgw.buckets.data (pool 12) is the same ec:2+1 shape.

The rule's premise is also wrong for EC: its description claimed a single
OSD loss destroys data, but 2+1 carries a parity shard and tolerates one
OSD loss, the same as replica-2. Summary and description now say
"replicated" and drop that claim.

Gated on the exporter's own `type` label rather than moving the threshold.
Nudging 1.5 to 1.49 would keep a knife-edge and would also narrow the real
replica-2 -> replica-1 signal (1.0) this rule exists to catch.

NO COVERAGE GAP: a genuine EC redundancy loss raises POOL_NO_REDUNDANCY,
which is a live series in ceph_health_detail and is already deliberately in
scope for CephHealthWarn. That reads Ceph's own verdict instead of
inferring one from bytes, which is the right instrument — an EC pool that
loses a shard does not move its stored/used ratio at all.

VERIFIED against live Prometheus (read-only apiserver proxy, REN-36), using
the expression as serialized from this file:
  * 7d replay, old expr: pool 15 matches 49 samples (defect reproduced)
  * 7d replay, new expr: 0 matches
  * fire-window replay (12:00-16:30 UTC): old matches pool 15 at 231/271
    steps, new matches nothing
  * positive control, new expr with threshold raised 1.5->3.5: selects
    replicated pools 1,3,5,6,7,13,14 and excludes both EC pools (12,15) —
    the filter removes exactly the EC pools and nothing else
  * evaluated cleanly across 17 distinct mgr instances over 30d, so the
    on(pool_id) join does not break on mgr failover

BLAST RADIUS: none to workloads. This edits one PrometheusRule; Prometheus
hot-reloads rule files and no pod restarts. Worst case is alerting scope on
one rule. Nothing writes to the cluster, no Ceph object is touched.

REVERT: revert this commit. One file, no state left behind.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Co-Authored-By: Paperclip <noreply@paperclip.ing>
2026-09-25 23:18:58 +00:00
argus-bot (Paperclip service account) f8fc0c8f1b Merge pull request 'docs(paperclip): record why the paperclip KS has no monitoring dependsOn edge (REN-86)' (#985) from atlas/ren-86-paperclip-dependson-monitoring into master 2026-09-25 23:17:55 +00:00
atlas-botandClaude Opus 5 1de7071ea9 docs(paperclip): record why this KS has no monitoring edge (REN-86)
ci/woodpecker/pr/ci-scripts-test Pipeline was successful
ci/woodpecker/pr/ci-manifests-test Pipeline was successful
ci/woodpecker/pr/pr-review Pipeline was successful
REN-86 asked for one field: `- name: monitoring` on the `paperclip`
Kustomization's dependsOn, because apps/paperclip/prometheus-read-rbac.yaml
(PR #984) puts a Role and a RoleBinding in namespace `monitoring` and a
from-scratch bootstrap was expected to fail applying them.

The premise does not hold, so the field is not added and the reasoning is
written down instead:

- Namespace `monitoring` is not created by the `monitoring` Kustomization. It
  is declared in kubernetes/infrastructure/namespaces/namespaces.yaml, applied
  by `infrastructure`, which this Kustomization already dependsOn.
- `infrastructure` runs wait: false, so it applies the namespaces on its first
  pass and only its healthChecks gate readiness. It cannot report Ready before
  the namespace exists, and this Kustomization cannot start before that.
- Role and RoleBinding are core rbac.authorization.k8s.io/v1 kinds, and a
  RoleBinding may reference a Role that does not exist yet. Nothing on this
  path needs a kube-prometheus-stack CRD or workload, so there is no analogue
  of the monitoring-rules/PrometheusRule split.

Adding the edge would also couple the Kustomization that carries the paperclip
pod to `monitoring` readiness, which itself waits on grafana-db,
kube-prometheus-stack, Loki, Alloy and blackbox-exporter for up to 30m.

Comments only: the parsed manifest is identical to master.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-09-25 23:09:27 +00:00
argus-bot (Paperclip service account) d3e759112f Merge PR #984: read-only Prometheus path via apiserver proxy + RBAC get (REN-36)
ci/woodpecker/cron/issue-fix Pipeline was successful
ci/woodpecker/cron/alert-monitor Pipeline was successful
Option B on REN-37, owner-approved: reach Prometheus through the apiserver
service proxy under a Role holding one verb, instead of an L4 allow on :9090
that could not tell GET /api/v1/query from the unauthenticated POST /-/quit
that --web.enable-lifecycle puts on the same port.

  ServiceAccount  paperclip/paperclip-prometheus-read
  Role            monitoring/paperclip-prometheus-read
                  get on services/proxy, resourceNames:
                  ["kube-prometheus-stack-prometheus:9090"]
  RoleBinding     monitoring/paperclip-prometheus-read -> that SA
                  (subject namespace: paperclip - load-bearing, cross-ns)
  paperclip.yaml  serviceAccountName + automountServiceAccountToken: true

Authored by svc-atlas, reviewed and merged by argus-bot: author is not the
merger. ci-manifests-test green on 35bcdf10 (kustomize build over the whole
tree). Reviewed against master 3a457bd6 in a fresh clone.

BLAST RADIUS: applying this restarts the paperclip pod (strategy: Recreate)
and every agent running in it. Nothing in production monitoring restarts -
Prometheus, Alertmanager, Loki and the ingress controllers are untouched.
The paperclip Flux Kustomization has wait: true, so a pod that does not come
back shows as a failed reconcile rather than silently.

REVERT - one step:

  git revert -m 1 <the sha of this merge commit>

That drops serviceAccountName, restores automountServiceAccountToken: false
and deletes prometheus-read-rbac.yaml; Flux prunes the ServiceAccount, Role
and RoleBinding on the next reconcile (paperclip Kustomization, prune: true).
It restarts the paperclip pod a second time, for the same reason the apply
does.

AGENT-FREE ESCAPE HATCH - use this if the pod does not come back, because
then there is no agent left to run the revert above. Flux re-applies the same
spec every 10m and overwrites a bare rollout undo; the suspend is what makes
the undo stick:

  flux -n flux-system suspend kustomization paperclip
  kubectl -n paperclip rollout undo deployment/paperclip
  # then land the git revert above, and afterwards:
  flux -n flux-system resume kustomization paperclip

Names as they are in this repo: `paperclip` is both the Flux Kustomization in
flux-system (clusters/homelab/paperclip.yaml) and the Deployment in namespace
paperclip. No revisionHistoryLimit is set anywhere under kubernetes/, so the
default 10 holds and a previous ReplicaSet exists to undo to. The undo
restores automountServiceAccountToken: false, which closes the read path at
once, before the RBAC objects are pruned. It rolls the pod template back
wholesale, so an image bump that landed after this merge is rolled back with
it - re-apply that after the resume.

Escape hatch text is the merger's, written into this merge commit because
merge condition 2 puts the revert recipe here. The diff is untouched.

Refs: REN-36, REN-37 (option B), REN-47 (review bar), REN-73 (merge card)
2026-09-25 21:41:40 +00:00
atlas-botandClaude Opus 5 35bcdf1043 feat(paperclip): read-only Prometheus path via apiserver proxy (REN-36)
ci/woodpecker/pr/ci-scripts-test Pipeline was successful
ci/woodpecker/pr/ci-manifests-test Pipeline was successful
ci/woodpecker/pr/pr-review Pipeline was successful
Owner picked option B on REN-37: reach Prometheus through the apiserver
service proxy under an RBAC Role holding one verb, instead of an L4 Cilium
allow on :9090.

The port cannot be the boundary. The chart leaves `reloadStrategy` unset, so
the operator defaults it to HTTP and appends `--web.enable-lifecycle`, which
puts `POST /-/quit` and `POST /-/reload` on :9090 with no auth in front of
them. An L4 allow cannot distinguish those from `GET /api/v1/query`. The
apiserver can: it maps HTTP method to RBAC verb, so a Role with only `get`
refuses both in the authorizer before the request reaches Prometheus.

  ServiceAccount  paperclip/paperclip-prometheus-read
  Role            monitoring/paperclip-prometheus-read
                  get on services/proxy, resourceNames:
                  ["kube-prometheus-stack-prometheus:9090"]
  RoleBinding     monitoring/paperclip-prometheus-read -> the SA above
  paperclip.yaml  serviceAccountName + automountServiceAccountToken: true

Shape copied from monitoring/ci-diagnostics-rbac.yaml, which has run this
same proxy path for the alert-monitor since 2026-07-16. No network-policy
edit: paperclip-egress already allows kube-apiserver on 6443.

BLAST RADIUS: applying this restarts the paperclip pod, and every agent with
it. Nothing in production monitoring restarts — Prometheus, Alertmanager,
Loki and the ingress controllers are untouched.

REVERT: revert this commit. One commit, four files, no state left behind;
Flux prunes the SA, Role and RoleBinding and rolls the pod back to no
mounted token.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-09-25 21:30:04 +00:00
argus-bot (Paperclip service account) 3a457bd63c Merge PR #978: record the egress dependency and the real revert recipe for the app-health probes (REN-21)
ci/woodpecker/cron/alert-monitor Pipeline was successful
Comment-only change to kubernetes/apps/monitoring-rules/probes-blackbox.yaml. Reviewed by argus-bot at head 49bd9271 against base 2b71dda1: 3 documents parse deep-equal, blackbox-http 20 targets before and after, git diff -U0 non-comment non-blank lines = 0, apps/gatus/configmap.yaml untouched. Revert recipe and blast-radius claims re-executed and confirmed.
2026-09-25 21:13:11 +00:00
atlas-botandClaude Opus 5 49bd927147 docs(monitoring): egress dependency, blast radius, tested revert recipe (REN-21)
ci/woodpecker/pr/ci-scripts-test Pipeline was successful
ci/woodpecker/pr/ci-manifests-test Pipeline was successful
ci/woodpecker/pr/pr-review Pipeline was successful
Comment-only. Rebuilt on top of master (2b71dda1) after #979 merged, so it
adds to that text instead of reverting it.

- EGRESS: names the two ingress-only Cilium policies in the monitoring
  namespace and where blackbox-exporter runs; counts re-verified at
  2b71dda1 (635 yaml files, 73 Cilium objects, 38 with egress/egressDeny,
  0 in monitoring, 1 CCNP scoped to reserved.health, 17 namespaces with
  an egress block).
- BLAST RADIUS: what breaks if that dependency is ever broken
  (BlackboxProbeFailing x3, BlackboxProbesAbsent stays silent), who
  notices (admin@renner.uno, ~10-11 min), and how fast it is undone.
- REVERT: replaced the claim with an executed recipe. All four git revert
  candidates CONFLICT at 2b71dda1; the two forward sed deletions were run
  and verified (blackbox-http 20 -> 17 and 20 -> 19).

No object changes: 3 documents deep-equal before/after under two
independent parsers, blackbox-http still 20 targets, and `git diff -U0`
has zero non-comment non-blank changed lines. apps/gatus/configmap.yaml
is not touched.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-09-25 21:06:51 +00:00
argus-bot (Paperclip service account)andPaperclip 2b71dda105 Merge PR #982: image-automation push identity is the flux account (REN-50)
ci/woodpecker/cron/alert-monitor Pipeline was successful
Comment-only change to kubernetes/infrastructure/image-automation/update-automation.yaml.

Reviewed by Argus (svc-argus/argus-bot). Verified comment-only: SHA256 of the comment-stripped file is 4ed11c66f18b8d15 before and after. No object field changes, so Flux's next reconcile is a no-op.

Revert: git revert 4f1c2cf1

Co-Authored-By: Paperclip <noreply@paperclip.ing>
2026-09-25 20:55:28 +00:00
atlas-bot (Paperclip service account)andPaperclip 4f1c2cf174 docs(image-automation): push identity is the flux account, not gitea_admin
ci/woodpecker/pr/ci-scripts-test Pipeline was successful
ci/woodpecker/pr/ci-manifests-test Pipeline was successful
ci/woodpecker/pr/pr-review Pipeline was successful
The comment on ImageUpdateAutomation/homelab named gitea_admin as the
owner of the bootstrap token that pushes writeback commits to master.
That is wrong. The pushing account is `flux` (Gitea uid 9): its
contribution history matches every `chore(image-automation)` commit on
master 1:1, while gitea_admin's own contributions stop at 2026-07-21.

Also separates two things the old wording ran together — the commit
author (security-bot@renner.uno, set in this spec) and the pushing
account (the token owner, not set here) — and records that writeback
failure is silent, since no commit is attempted unless a tracked image
moves.

Comment-only. The ImageUpdateAutomation object is byte-identical; no
Kubernetes object changes, nothing for Flux to reconcile.

Refs REN-50

Co-Authored-By: Paperclip <noreply@paperclip.ing>
2026-09-25 20:44:53 +00:00
security-bot b858b4aa4f chore(image-automation): bump lscr.io/linuxserver/lidarr:3.1.0.4875-ls11
ci/woodpecker/cron/issue-fix Pipeline was successful
ci/woodpecker/cron/alert-monitor Pipeline was successful
Updates managed by image-automation-controller.
2026-09-25 20:38:54 +00:00
k.renner 0ec61a3e61 Merge branch 'master' into docs/paperclip-claude-token
ci/woodpecker/pr/ci-scripts-test Pipeline was successful
ci/woodpecker/pr/pr-review Pipeline was successful
2026-09-25 20:07:04 +00:00
argus-bot (Paperclip service account) 46b32d4ec3 Merge pull request 'docs(monitoring): correct the CNP reasoning, record the egress dependency (REN-21)' (#979) from docs/probe-cnp-egress-and-status-caveats into master
ci/woodpecker/cron/alert-monitor Pipeline was successful
Comment-only. No Kubernetes object changes on either file: all 3 probe documents deep-equal to master (blackbox-http 20 targets), ConfigMap/gatus-config deep-equal with data["config.yaml"] byte-identical at sha256 8886ef21...6472 (6572 bytes), so Reloader does not roll gatus. Non-comment non-blank changed lines vs merge base 0a82d61f: 0. Reviewed and verified by argus-bot at head 9142b78a; the REVERT recipe was re-tested against its own commit.
2026-09-25 20:01:41 +00:00
claude-botandClaude Opus 5.5 7b66a8f4cf docs(paperclip): Claude connection needs a setup-token value
ci/woodpecker/pr/ci-scripts-test Pipeline was successful
ci/woodpecker/pr/pr-review Pipeline was successful
The local-login connection stores only the ~8h OAuth access token and
Paperclip never refreshes Anthropic credentials (subscription values
are injected read-only as CLAUDE_CODE_OAUTH_TOKEN). It expired 8h after
the login and every run failed with 'terminal access failure'.
Replacing the secret value with a claude setup-token token fixed it.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-09-25 21:59:31 +02:00
k.renner fd7b4f2eff Merge pull request 'fix(paperclip): raise memory limit to 32Gi (OOMKilled)' (#980) from fix/paperclip-memory into master
ci/woodpecker/cron/alert-monitor Pipeline was successful
Reviewed-on: k.renner/homelab#980
2026-09-25 19:50:42 +00:00
9142b78a18 docs(monitoring): fix the REVERT sentence this PR itself falsifies (REN-21)
ci/woodpecker/pr/ci-scripts-test Pipeline was successful
ci/woodpecker/pr/ci-manifests-test Pipeline was successful
ci/woodpecker/pr/pr-review Pipeline was successful
Comment-only, one sentence, one file. Wording is Argus's from the #979
review (REN-38).

The REVERT paragraph ended with "The paperless block below DOES revert
cleanly on its own with `git revert -m 1 0a82d61f`". True at 0a82d61f,
false at bd8690eb, because this same PR edits the paperless block:

  from 0a82d61f:  revert -m 1 0a82d61f -> CLEAN     revert -m 1 16238d39 -> CONFLICT
  from bd8690eb:  revert -m 1 0a82d61f -> CONFLICT  revert -m 1 16238d39 -> CONFLICT

Reproduced here: at bd8690eb the collision is one region, `<<<<<<< HEAD`
at 155 through `>>>>>>>` at 198, the whole paperless block against an
empty side. So the advice failed in exactly the case it was written for
— someone reverting the paperless probe under pressure, four lines below
a warning not to trust the natural resolution on this file. The new text
says what actually happens and how to resolve it, and stays true as the
comment block keeps changing, because it no longer promises clean.

Bar re-verified at this commit, both files against master, js-yaml:

  probes-blackbox.yaml   docs base=3 head=3, all deep-equal=true
                         http_2xx/20, http_2xx_wan_edge/3, tcp_connect/2
  gatus/configmap.yaml   ConfigMap/gatus-config deep-equal=true
                         data["config.yaml"] sha256 8886ef21…6472 both
                         sides, identical=true, bytes=6572
  git diff -U0 vs master, non-comment non-blank lines: 0

apps/gatus/configmap.yaml is not touched by this commit at all.

Production constraint: nothing applied, restarted or re-rendered. The
public status.renner.uno page does not roll — ConfigMap data is
unchanged, so configmap.reloader.stakater.com/reload has nothing to act
on.

Revert: `git revert <this-sha>` restores the previous sentence and
nothing else.

Refs REN-21, REN-38, REN-44.

Co-Authored-By: Paperclip <noreply@paperclip.ing>
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-09-25 19:40:06 +00:00
svc-atlasandPaperclip bd8690ebdc docs(monitoring): correct the CNP reasoning, record the egress dependency (REN-21)
ci/woodpecker/pr/ci-manifests-test Pipeline was successful
ci/woodpecker/pr/ci-scripts-test Pipeline was successful
ci/woodpecker/pr/pr-review Pipeline was successful
Comment-only. Every parsed object in both files is byte-identical to
master at 0a82d61f, verified with js-yaml; zero non-comment lines change.

Review follow-ups from REN-22 on the merged #976/#977 probes:

1. The CNP argument was right in its conclusion and wrong in its framing.
   cnp-cross-namespace-allow-apps-gatus-to-monitored-services DOES apply to
   blackbox-exporter — its Generalization section names it. We are safe
   because the allow it demands is already present, not because the note is
   about gatus. The old wording is the sentence that makes the next person
   skip the check for the next namespace.

2. Records the load-bearing egress fact, which was written down nowhere.
   Cilium enforces at both ends; blackbox-exporter can send only because no
   policy selecting a monitoring endpoint declares an `egress:` block.
   Verified across the repo: 73 Cilium policies, 38 with egress, none in
   monitoring, and the one CCNP is scoped to `reserved.health`. 17 other
   namespaces already have an egress block, so a routine hardening pass on
   monitoring would break these three targets and leave the *.monitoring.svc
   ones working.

3. Extends the 200-vs-3xx caveat to all three new targets, not just
   paperless. The repo evidence behind every one of them establishes only
   `< 400` (kubelet httpGet accepts 200-399; lidarr.yaml:29's `curl -f`
   without -L exits 0 on a 302). It proves the paths are ungated, not that
   they answer 200. A 3xx gets reverted, not widened.

4. Records the tested revert recipe for #976 in the file. `git revert -m 1
   16238d39` conflicts and the natural resolution silently drops paperless
   too.

5. Corrects the stale "needs a CiliumNetworkPolicy first" claim in
   apps/gatus/configmap.yaml. The correction is written in the manifest
   header, ABOVE `data:`, not in place: the stale sentence sits inside the
   `config.yaml: |` block scalar, and gatus carries
   configmap.reloader.stakater.com/reload, so editing it in place would roll
   the gatus Deployment for a comment. ConfigMap data sha256 is unchanged.

Production constraint: nothing is applied, restarted or re-rendered by this
change. No workload, namespace, policy or probe target is touched.

Revert: `git revert -m 1 <merge-sha>`, or drop either file alone with
`git checkout 0a82d61f -- <path>`.

Refs REN-21, REN-22.

Co-Authored-By: Paperclip <noreply@paperclip.ing>
2026-09-25 19:18:37 +00:00
228 changed files with 14139 additions and 482 deletions
+1 -1
View File
@@ -101,7 +101,7 @@ steps:
bash scripts/ci/make-diag-kubeconfig.sh
- name: alert-triage-agent
image: gitea.renner.uno/gitea_admin/ci-claude:2.1.280
image: gitea.renner.uno/gitea_admin/ci-claude:2.1.289
environment:
CLAUDE_CODE_OAUTH_TOKEN:
from_secret: claude_code_oauth_token
+66
View File
@@ -0,0 +1,66 @@
# Paperclip agent runtime images (REN-284 / REN-286): the stock
# agent-runtime-claude plus a tool set, one image per sandbox environment.
# Built with kaniko like build-ci-images.yml and pushed with the same
# ci_images_token (package read+write only, see the header there).
#
# Own workflow, not a step in build-ci-images.yml. A change to that file
# rebuilds all of its images at once and fills the 24-CPU woodpecker-ci-quota;
# on the REN-286 merge (pipeline 11306) this step then got no pod
# ("exceeded quota") and the go image was never built. Here it runs only when
# its own sources change, and it can be re-run alone with a deployment to
# target `build-agent-runtime`, without rebuilding the other images.
#
# The name looks odd on purpose. The kubernetes sandbox plugin keeps the image
# name and tag `agent-runtime-claude:v1` and swaps only the registry prefix
# (`imageRegistry`), replacing host + org. So each variant needs its own
# prefix with the same name under it:
# imageRegistry gitea.renner.uno/konairius/agent-runtime-go
# -> gitea.renner.uno/konairius/agent-runtime-go/agent-runtime-claude:v1
# `v1` is what the plugin pulls and moves on every build; the date tag is the
# rollback point. konairius/ because the ci_images_token can push there and
# it is the target of the gitea_admin/* migration (#330).
when:
- event: push
branch: master
path:
- "ci/images/agent-runtime-*/**"
- ".woodpecker/build-agent-runtime.yml"
- event: deployment
evaluate: 'CI_PIPELINE_DEPLOY_TARGET == "build-agent-runtime"'
steps:
- name: build-agent-runtime
image: registry.gitlab.com/gitlab-ci-utils/container-images/kaniko:v1.25.19-debug@sha256:7795cec509a50a71378cc2c365f55c555ee3a05834d8eb1cd2552df5e66d44d8
directory: ci/images
# Context is ci/images (not the variant dir) so both Containerfiles can
# COPY the shared agent-runtime-common/ files.
# One pod, both images one after the other (kaniko --cleanup between
# builds), at 1 CPU so it still fits if it overlaps another pipeline.
backend_options:
kubernetes:
resources:
requests:
cpu: 100m
memory: 256Mi
limits:
cpu: "1"
memory: 4Gi
environment:
GITEA_USER: gitea_admin
GITEA_TOKEN:
from_secret: ci_images_token
commands:
- mkdir -p /kaniko/.docker
- AUTH=$(printf '%s:%s' "$GITEA_USER" "$GITEA_TOKEN" | base64 | tr -d '\n')
- printf '{"auths":{"gitea.renner.uno":{"auth":"%s"}}}' "$AUTH" > /kaniko/.docker/config.json
- TAG=$(date +%Y-%m-%d)
- |
for VARIANT in go ops; do
/kaniko/executor \
--cleanup \
--context . \
--dockerfile "agent-runtime-$VARIANT/Containerfile" \
--destination "gitea.renner.uno/konairius/agent-runtime-$VARIANT/agent-runtime-claude:$TAG" \
--destination "gitea.renner.uno/konairius/agent-runtime-$VARIANT/agent-runtime-claude:v1" \
|| exit 1
done
+17 -11
View File
@@ -26,8 +26,14 @@
# 38-reference change tracked separately in #330 rather than bundled here.
# Note this pipeline runs no LLM agent, so the exfil path that motivated the
# other cutovers does not apply to it.
#
# Push builds run on master only. Without the branch filter a feature branch
# that touches this file started all steps at once: it pushed unreviewed
# images and used the whole woodpecker-ci-quota, so the PR checks could not
# get a pod (REN-286).
when:
- event: push
branch: master
path:
- "ci/images/**"
- "secret-rotator/**"
@@ -37,7 +43,7 @@ when:
steps:
- name: build-ansible
image: registry.gitlab.com/gitlab-ci-utils/container-images/kaniko:v1.25.18-debug
image: registry.gitlab.com/gitlab-ci-utils/container-images/kaniko:v1.25.19-debug@sha256:7795cec509a50a71378cc2c365f55c555ee3a05834d8eb1cd2552df5e66d44d8
directory: ci/images/ansible
depends_on: []
# Only rebuild when THIS image's source (or the pipeline file) changed, or
@@ -65,7 +71,7 @@ steps:
--destination gitea.renner.uno/gitea_admin/ci-ansible:latest
- name: build-k8s
image: registry.gitlab.com/gitlab-ci-utils/container-images/kaniko:v1.25.18-debug
image: registry.gitlab.com/gitlab-ci-utils/container-images/kaniko:v1.25.19-debug@sha256:7795cec509a50a71378cc2c365f55c555ee3a05834d8eb1cd2552df5e66d44d8
directory: ci/images/k8s
depends_on: []
when:
@@ -89,7 +95,7 @@ steps:
--destination gitea.renner.uno/gitea_admin/ci-k8s:latest
- name: build-vmtest
image: registry.gitlab.com/gitlab-ci-utils/container-images/kaniko:v1.25.18-debug
image: registry.gitlab.com/gitlab-ci-utils/container-images/kaniko:v1.25.19-debug@sha256:7795cec509a50a71378cc2c365f55c555ee3a05834d8eb1cd2552df5e66d44d8
directory: ci/images/vmtest
depends_on: []
when:
@@ -113,7 +119,7 @@ steps:
--destination gitea.renner.uno/gitea_admin/ci-vmtest:latest
- name: build-tofu
image: registry.gitlab.com/gitlab-ci-utils/container-images/kaniko:v1.25.18-debug
image: registry.gitlab.com/gitlab-ci-utils/container-images/kaniko:v1.25.19-debug@sha256:7795cec509a50a71378cc2c365f55c555ee3a05834d8eb1cd2552df5e66d44d8
directory: ci/images/tofu
depends_on: []
when:
@@ -144,7 +150,7 @@ steps:
# Runtime image, not CI tooling: a static musl binary in a FROM-scratch image,
# used as the base for secret-rotation CronJobs. Replaces per-job inline Python.
- name: build-secret-rotator
image: registry.gitlab.com/gitlab-ci-utils/container-images/kaniko:v1.25.18-debug
image: registry.gitlab.com/gitlab-ci-utils/container-images/kaniko:v1.25.19-debug@sha256:7795cec509a50a71378cc2c365f55c555ee3a05834d8eb1cd2552df5e66d44d8
directory: secret-rotator
depends_on: []
when:
@@ -195,7 +201,7 @@ steps:
#
# The gitea_admin/ copy stays until nothing references it any more.
- name: build-alpine-jq
image: registry.gitlab.com/gitlab-ci-utils/container-images/kaniko:v1.25.18-debug
image: registry.gitlab.com/gitlab-ci-utils/container-images/kaniko:v1.25.19-debug@sha256:7795cec509a50a71378cc2c365f55c555ee3a05834d8eb1cd2552df5e66d44d8
directory: ci/images/alpine-jq
depends_on: []
when:
@@ -248,7 +254,7 @@ steps:
# note on build-alpine-jq. Anything an app needs while the cluster is still
# being built cannot live only in that cluster's own registry.
- name: build-cni-plugins
image: registry.gitlab.com/gitlab-ci-utils/container-images/kaniko:v1.25.18-debug
image: registry.gitlab.com/gitlab-ci-utils/container-images/kaniko:v1.25.19-debug@sha256:7795cec509a50a71378cc2c365f55c555ee3a05834d8eb1cd2552df5e66d44d8
directory: ci/images/cni-plugins
depends_on: []
when:
@@ -290,7 +296,7 @@ steps:
# gitea.renner.uno is not there to serve it. A cold-rebuild rehearsal left
# paperless in Init:ErrImagePull on exactly this image.
- name: build-alpine-openssl
image: registry.gitlab.com/gitlab-ci-utils/container-images/kaniko:v1.25.18-debug
image: registry.gitlab.com/gitlab-ci-utils/container-images/kaniko:v1.25.19-debug@sha256:7795cec509a50a71378cc2c365f55c555ee3a05834d8eb1cd2552df5e66d44d8
directory: ci/images/alpine-openssl
depends_on: []
when:
@@ -327,7 +333,7 @@ steps:
# Ansible converge. Not a ci-* image -- it is a runtime artifact -- but it
# builds the same way and lands in the same registry so the audit sees it.
- name: build-heating-can
image: registry.gitlab.com/gitlab-ci-utils/container-images/kaniko:v1.25.18-debug
image: registry.gitlab.com/gitlab-ci-utils/container-images/kaniko:v1.25.19-debug@sha256:7795cec509a50a71378cc2c365f55c555ee3a05834d8eb1cd2552df5e66d44d8
directory: ci/images/heating-can
depends_on: []
when:
@@ -354,7 +360,7 @@ steps:
# services (public Ingress hosts -> TLS passthrough -> Traefik ClusterIP).
# Runtime artifact like heating-can; same registry so the audit tracks it.
- name: build-netbird-service-sync
image: registry.gitlab.com/gitlab-ci-utils/container-images/kaniko:v1.25.18-debug
image: registry.gitlab.com/gitlab-ci-utils/container-images/kaniko:v1.25.19-debug@sha256:7795cec509a50a71378cc2c365f55c555ee3a05834d8eb1cd2552df5e66d44d8
directory: ci/images/netbird-service-sync
depends_on: []
when:
@@ -380,7 +386,7 @@ steps:
# bird: BGP daemon for the pod-network mesh over pod0 (#576). Runtime
# artifact like heating-can; same registry so the audit tracks it.
- name: build-bird
image: registry.gitlab.com/gitlab-ci-utils/container-images/kaniko:v1.25.18-debug
image: registry.gitlab.com/gitlab-ci-utils/container-images/kaniko:v1.25.19-debug@sha256:7795cec509a50a71378cc2c365f55c555ee3a05834d8eb1cd2552df5e66d44d8
directory: ci/images/bird
depends_on: []
when:
+69
View File
@@ -0,0 +1,69 @@
# Paperclip server image (REN-401): upstream paperclipai/paperclip at a pinned
# master commit plus the patches in ci/images/paperclip/. Needed while the k8s
# sandbox fix (upstream PR #13733) is not merged; see the README there for how
# to go back to upstream nightly.
#
# Own workflow for the reason given in build-agent-runtime.yml: a step in
# build-ci-images.yml runs on every change to that file and competes for the
# woodpecker-ci-quota. Re-run alone with a deployment to target
# `build-paperclip`.
#
# Tag `build.<unix-ts>` is what the Flux ImagePolicy `paperclip` sorts on
# (image-automation/paperclip.yaml); image automation then rolls it out.
# konairius/ and ci_images_token as for the agent-runtime images.
when:
- event: push
branch: master
path:
- "ci/images/paperclip/**"
- ".woodpecker/build-paperclip.yml"
- event: deployment
evaluate: 'CI_PIPELINE_DEPLOY_TARGET == "build-paperclip"'
steps:
- name: prepare-source
image: gitea.renner.uno/gitea_admin/ci-k8s:2026-09-08
commands:
- sh ci/images/paperclip/prepare.sh build/paperclip-src
- name: build-paperclip
image: registry.gitlab.com/gitlab-ci-utils/container-images/kaniko:v1.25.19-debug@sha256:7795cec509a50a71378cc2c365f55c555ee3a05834d8eb1cd2552df5e66d44d8
directory: build/paperclip-src
depends_on: [prepare-source]
# Rust runner + UI + server build in one pod. The server build alone sets
# a 4 GiB Node heap, so the memory limit is the LimitRange max (8Gi).
backend_options:
kubernetes:
resources:
requests:
cpu: "1"
memory: 2Gi
limits:
cpu: "4"
memory: 8Gi
environment:
GITEA_USER: gitea_admin
GITEA_TOKEN:
from_secret: ci_images_token
commands:
- . ../../ci/images/paperclip/upstream.env
- mkdir -p /kaniko/.docker
- AUTH=$(printf '%s:%s' "$GITEA_USER" "$GITEA_TOKEN" | base64 | tr -d '\n')
- printf '{"auths":{"gitea.renner.uno":{"auth":"%s"}}}' "$AUTH" > /kaniko/.docker/config.json
- TAG=build.$(date +%s)
# Same target and build args as upstream's docker.yml for nightly.
# --compressed-caching=false: pipeline 11717 was killed at the 8Gi limit
# (exit 137) in the server build; kaniko otherwise holds compressed
# layer tarballs in memory next to the 4 GiB Node heap.
- |
/kaniko/executor \
--context . \
--dockerfile Dockerfile.kaniko \
--target production \
--skip-unused-stages \
--snapshot-mode=redo \
--compressed-caching=false \
--build-arg PAPERCLIP_BUILD_COMMIT=$PAPERCLIP_COMMIT \
--build-arg PAPERCLIP_BUILD_VERSION=$PAPERCLIP_VERSION \
--build-arg CLI_TOOLS_CACHE_EPOCH=$(date -u +%G-W%V) \
--destination gitea.renner.uno/konairius/paperclip:$TAG
+1 -1
View File
@@ -131,7 +131,7 @@ steps:
# --build-arg to the resolved version (not "latest") guarantees the tag and
# the image content agree even if a new release lands mid-run.
- name: build
image: registry.gitlab.com/gitlab-ci-utils/container-images/kaniko:v1.25.18-debug
image: registry.gitlab.com/gitlab-ci-utils/container-images/kaniko:v1.25.19-debug@sha256:7795cec509a50a71378cc2c365f55c555ee3a05834d8eb1cd2552df5e66d44d8
directory: ci/images/claude
depends_on: [decide]
environment:
+100 -17
View File
@@ -17,30 +17,44 @@
# here is a static check that either passes or fails on the checkout alone, so it
# can gate PRs without becoming a bottleneck or a flake source.
when:
# Path-filtered on purpose, unlike ci-scripts-test.yml. That pipeline is one
# step on one already-cached image, so running it everywhere is free; this one
# pulls three images and builds every kustomization in the tree, which is real
# Path-filtered on purpose, unlike ci-scripts-test.yml. That pipeline is two
# steps on already-cached images, so running it everywhere is free; this one
# pulls four images and builds every kustomization in the tree, which is real
# cost to put on a docs-only PR. The filter covers everything the steps actually read:
# kubernetes/** for the manifests and scripts, .woodpecker/** for the lint (and
# so an edit to this file re-runs its own checks).
# kubernetes/** for the manifests, scripts and promtool suites, .woodpecker/**
# for the lint (and so an edit to this file re-runs its own checks), and the
# promtool driver script by name.
#
# That last entry is NOT covered by kubernetes/**: promtool-rules.sh lives
# under scripts/, so without it a PR that only edits the script would never run
# the check it drives. It is listed as one file rather than scripts/ci/**
# because the rest of that directory is CI-agent helpers with nothing to do
# with this pipeline, and pulling four images for them is the cost this filter
# exists to avoid. Their own tests run in ci-scripts-test.yml on every PR.
- event: pull_request
path:
- "kubernetes/**"
- ".woodpecker/**"
- "scripts/ci/promtool-rules.sh"
- "scripts/ci/yaml-citations.sh"
# ADDING A THIRD DISCOVERY CHECK: kustomize-build and shellcheck both hand-roll
# the same shape — `find`, a floor guard against empty discovery, then a
# file-fed `while read`. Two copies is deliberate: the two traps being commented
# around (BusyBox find lacking `-printf`, and a piped loop running in a subshell
# where `fail` cannot propagate) are different, and both are worth spelling out
# where they bite. A third instance is the point to stop copying and factor it
# into a shared script under `scripts/ci/` — which is already covered by
# ci-scripts-test.yml, so it would gain unit tests in the process.
# THE THIRD DISCOVERY CHECK WENT TO A SCRIPT. kustomize-build and shellcheck
# both hand-roll the same shape — `find`, a floor guard against empty discovery,
# then a file-fed `while read`. Two copies was deliberate: the two traps being
# commented around (BusyBox find lacking `-printf`, and a piped loop running in
# a subshell where `fail` cannot propagate) are different, and both are worth
# spelling out where they bite. An earlier revision of this comment said a third
# instance would be the point to stop copying and factor it into `scripts/ci/`,
# where it would gain unit tests — and that is what `promtool` below does. Its
# discovery, floors and guards live in scripts/ci/promtool-rules.sh and are
# tested by scripts/ci/test-promtool-rules.sh on every PR via
# ci-scripts-test.yml. A FOURTH inline copy should go the same way; do not add
# one here.
#
# Every step carries `depends_on: []` so all four run in PARALLEL and every
# Every step carries `depends_on: []` so all six run in PARALLEL and every
# failure shows in one run. Woodpecker's default is sequential, which would stop
# at the first failure and make a contributor fix-and-repush to discover the
# next — and these four are independent, cheap, offline checks with no ordering
# next — and these six are independent, cheap, offline checks with no ordering
# between them. Keep it on every step: `depends_on` is per-step, so dropping it
# from one silently re-serialises that step behind the others.
steps:
@@ -158,7 +172,7 @@ steps:
# whenever it trails the deployed server. If you bump the server, bump here.
- name: woodpecker-lint
depends_on: [] # see note above `steps:`
image: woodpeckerci/woodpecker-cli:v3.18.0-alpine
image: woodpeckerci/woodpecker-cli:v3.18.1-alpine@sha256:7eac3c4254befc1ba1e65269c3304c370b6032530b7386fc0c7648378fdd0516
commands:
- |
set -eu
@@ -185,7 +199,7 @@ steps:
# separately rather than one this step quietly implies is covered.
- name: shellcheck
depends_on: [] # see note above `steps:`
image: koalaman/shellcheck-alpine:v0.11.0
image: koalaman/shellcheck-alpine:v0.11.0@sha256:9955be09ea7f0dbf7ae942ac1f2094355bb30d96fffba0ec09f5432207544002
commands:
- |
set -eu
@@ -258,3 +272,72 @@ steps:
exit 1
fi
echo "ok no digest pins under openbao/rotation/"
# Machine-check the alert rules: parse every PrometheusRule, run the committed
# promtool unit suites, then damage the rules on purpose and require the suites
# to notice. Everything it does lives in scripts/ci/promtool-rules.sh; read
# that file and kubernetes/apps/monitoring-rules/tests/README.md for the why.
#
# The gap it closes: the other four steps prove a PrometheusRule assembles into
# valid YAML and nothing more — not that an expression parses, not that a label
# join matches anything, not that a `for` window does what its comment claims.
# On REN-129 the CNPG surge rule was written `for: 2m`, which fires on six of
# seven measured nights and would have mailed the owner twice a night at 04:16
# and 04:22 local for a backlog that clears itself. Nothing here would have
# caught it, and the arithmetic that did catch it was hand-written from scratch
# twice, in two runs, and thrown away both times because there was nowhere in
# the repo to commit it. REN-152 retired that rule; its `for` margin is now
# guarded by mutations.txt:backlog-for-12m.
#
# Offline, like the rest of this pipeline: no cluster, no registry, no secrets,
# no network. promtool reads files and exits.
#
# IMAGE — prom/prometheus, not a registry-local ci-* image, and pinned to an
# exact upstream version rather than a dated tag. The dated-tag convention
# guarded by no-digest-pins above is about OUR images, whose digests are
# garbage-collected out from under a pin; this is upstream and immutable.
#
# The version must be 3.x, and that is not a preference. The cluster runs
# whatever kube-prometheus-stack >= 72.0.0 ships, which is Prometheus 3, and
# alert `for` evaluation is version-sensitive — a 2.x promtool would be
# checking a different evaluator than production, so the margins the suites
# assert would be claims about the wrong program. promtool-rules.sh asserts the
# major version it was handed and fails on 2.x, so a careless bump here is a
# red step rather than a quietly wrong check. Keep this at the latest stable
# 3.x, per the standing rule that any software uses the latest stable version.
#
# This image is NOT covered by image-automation (same reason as
# woodpecker-lint above: a Woodpecker pipeline file has no apiVersion/kind, so
# an $imagepolicy marker here is silently ignored — fluxcd/flux2#2826). The
# bump is manual.
#
# `prom/prometheus` is busybox-based and ships /bin/sh, so it can run a
# `commands:` block — unlike the plain woodpecker-cli tag, which cannot. Its
# find/grep/awk/sed are BusyBox, which is why promtool-rules.sh avoids
# `find -printf` and `grep -r --include`; it was verified against BusyBox
# 1.35.0 as well as GNU. The image also declares `USER nobody`, so the script
# writes its stripped mirror under mktemp and never into the workspace.
- name: promtool
depends_on: [] # see note above `steps:`
image: prom/prometheus:v3.15.0@sha256:efd719c99d83b060d9daefdcf00360461adf279f45ef5391f8d111892118753e
commands:
- sh scripts/ci/promtool-rules.sh
# Comments cite other YAML blocks by anchor name, never by line number
# (REN-183; the exact syntax is in CONTRIBUTING.md, not repeated here because
# an example written in this comment would itself be checked). Line numbers drift on any edit
# above them and nothing noticed: three drift fixes were merged by hand
# before this step existed. This fails on a new line-number citation and on
# a citation whose file or anchor marker does not exist.
# Existence only — it never judges whether the anchored block still says
# what the citing comment claims, so ordinary edits cannot turn it red.
#
# It scans every YAML file in the checkout, but this pipeline only runs on
# the paths in `when:` above, so an edit confined to ansible/ or esphome/ is
# checked on the next PR that does touch kubernetes/ or .woodpecker/.
# Self-test: scripts/ci/test-yaml-citations.sh, in ci-scripts-test.yml.
- name: yaml-citations
depends_on: [] # see note above `steps:`
image: gitea.renner.uno/gitea_admin/ci-k8s:2026-09-08
commands:
- sh scripts/ci/yaml-citations.sh
+34 -4
View File
@@ -8,15 +8,45 @@
# against adversarial PR input. Running it here fails the offending PR's checks
# before it can merge.
#
# scripts/ci/test-promtool-rules.sh is the same idea for the alert-rule gate.
# What it tests is not whether promtool evaluates PromQL — ci-manifests-test.yml
# does that with the real binary against the real rules — but whether
# promtool-rules.sh REFUSES TO REPORT SUCCESS when it has checked nothing: zero
# manifests discovered, zero suites discovered, a `rule_files` path that does not
# resolve (promtool warns, loads zero rules, and passes every assertion), a
# mutation the suites no longer catch. Those are the states a green pipeline
# cannot tell apart from real coverage, so they need a test that asserts the
# failure. It stubs promtool, so it needs neither the binary nor the heavy image.
#
# Both are unfiltered by path on purpose: this pipeline is two steps on one
# already-cached image, so running it everywhere is free, and a guard whose test
# only runs when someone remembers to touch the right directory is not a guard.
#
# Only in homelab (scripts/ci/ lives here); the file is not deployed to the
# mirrored repos, so it does not run on their PRs. The test is offline (no token,
# no network, no cluster) — the ci-claude image just provides sh + jq, and it is
# already pulled by pr-review.yml on the same event, so the runner has it cached.
# mirrored repos, so it does not run on their PRs. All tests here are offline (no
# token, no network, no cluster) — the ci-claude image just provides sh + jq, and
# it is already pulled by pr-review.yml on the same event, so the runner has it
# cached.
when:
- event: pull_request
# `depends_on: []` on every step so they run in parallel and one failure does not hide
# the other. Same reasoning as the note above `steps:` in ci-manifests-test.yml.
steps:
- name: model-selection-tests
image: gitea.renner.uno/gitea_admin/ci-claude:2.1.280
depends_on: []
image: gitea.renner.uno/gitea_admin/ci-claude:2.1.289
commands:
- sh scripts/ci/test-model-selection.sh
- name: promtool-rules-guard-tests
depends_on: []
image: gitea.renner.uno/gitea_admin/ci-claude:2.1.289
commands:
- sh scripts/ci/test-promtool-rules.sh
- name: yaml-citations-guard-tests
depends_on: []
image: gitea.renner.uno/gitea_admin/ci-claude:2.1.289
commands:
- sh scripts/ci/test-yaml-citations.sh
+1 -1
View File
@@ -13,7 +13,7 @@ when:
steps:
- name: validate-secrets
image: alpine:3.24.1
image: alpine:3.24.2@sha256:294b683cb724975bec92580e1e685676bd4b50bda910ddb8c51d4cabeaec77e6
environment:
TF_VAR_proxmox_api_url:
from_secret: proxmox_api_url
+1 -1
View File
@@ -26,7 +26,7 @@ steps:
# fetch-models.sh response mapping. No cluster, no secrets, no network — the
# ci-claude image just provides sh + jq. Keeps the flag-injection regression
# test from rotting (it exercises the exact injection shapes).
image: gitea.renner.uno/gitea_admin/ci-claude:2.1.280
image: gitea.renner.uno/gitea_admin/ci-claude:2.1.289
commands:
- sh scripts/ci/test-model-selection.sh
+1 -1
View File
@@ -62,7 +62,7 @@ steps:
- bash scripts/ci/make-diag-kubeconfig.sh
- name: issue-fix-agent
image: gitea.renner.uno/gitea_admin/ci-claude:2.1.280
image: gitea.renner.uno/gitea_admin/ci-claude:2.1.289
environment:
CLAUDE_CODE_OAUTH_TOKEN:
from_secret: claude_code_oauth_token
+1 -1
View File
@@ -65,7 +65,7 @@ when:
steps:
- name: pr-review-agent
image: gitea.renner.uno/gitea_admin/ci-claude:2.1.280
image: gitea.renner.uno/gitea_admin/ci-claude:2.1.289
environment:
CLAUDE_CODE_OAUTH_TOKEN:
from_secret: claude_code_oauth_token
+3 -3
View File
@@ -18,12 +18,12 @@ when:
steps:
- name: iac-scan
image: aquasec/trivy:latest
image: aquasec/trivy:latest@sha256:af6acf9a6b85dfe389a1941505c0ce9efef52a4719635e1a962f022a3d855daa
commands:
- trivy fs --format json -o trivy-iac.json --severity CRITICAL,HIGH --ignore-unfixed .
- name: image-scans
image: aquasec/trivy:latest
image: aquasec/trivy:latest@sha256:af6acf9a6b85dfe389a1941505c0ce9efef52a4719635e1a962f022a3d855daa
commands:
- trivy image --download-db-only
- |
@@ -70,7 +70,7 @@ steps:
# this step is skipped — otherwise we'd fork-bomb PRs.
when:
- branch: master
image: gitea.renner.uno/gitea_admin/ci-claude:2.1.280
image: gitea.renner.uno/gitea_admin/ci-claude:2.1.289
environment:
CLAUDE_CODE_OAUTH_TOKEN:
from_secret: claude_code_oauth_token
+1 -1
View File
@@ -30,7 +30,7 @@ when:
steps:
- name: update-audit-agent
image: gitea.renner.uno/gitea_admin/ci-claude:2.1.280
image: gitea.renner.uno/gitea_admin/ci-claude:2.1.289
environment:
CLAUDE_CODE_OAUTH_TOKEN:
from_secret: claude_code_oauth_token
+5 -5
View File
@@ -17,7 +17,7 @@ when:
steps:
- name: checkout-notes
image: gitea.renner.uno/gitea_admin/ci-claude:2.1.280
image: gitea.renner.uno/gitea_admin/ci-claude:2.1.289
pull: true
environment:
WIKI_BOT_TOKEN:
@@ -54,7 +54,7 @@ steps:
- bash scripts/ci/make-diag-kubeconfig.sh
- name: distill
image: gitea.renner.uno/gitea_admin/ci-claude:2.1.280
image: gitea.renner.uno/gitea_admin/ci-claude:2.1.289
pull: true
environment:
CLAUDE_CODE_OAUTH_TOKEN:
@@ -89,14 +89,14 @@ steps:
-p
- name: audit
image: gitea.renner.uno/gitea_admin/ci-claude:2.1.280
image: gitea.renner.uno/gitea_admin/ci-claude:2.1.289
pull: true
commands:
# Findings are report lines in output/, not a pipeline failure.
- python3 -B notes/bin/wiki_audit.py --vault "$$PWD/notes"
- name: consolidate
image: gitea.renner.uno/gitea_admin/ci-claude:2.1.280
image: gitea.renner.uno/gitea_admin/ci-claude:2.1.289
pull: true
environment:
CLAUDE_CODE_OAUTH_TOKEN:
@@ -145,7 +145,7 @@ steps:
exit $$rc
- name: push-notes
image: gitea.renner.uno/gitea_admin/ci-claude:2.1.280
image: gitea.renner.uno/gitea_admin/ci-claude:2.1.289
pull: true
environment:
WIKI_BOT_TOKEN:
+7
View File
@@ -0,0 +1,7 @@
# Contributing
## Citing other YAML from a comment
- Mark the block you cite with a comment line `# anchor: <name>` (kebab-case, unique in that file). If the block is inside a `|` block scalar, put the marker just above the key, never inside the scalar.
- Cite it as `path.yaml#<name>`, with the path relative to the citing file's directory or to the repo root. Never cite `path.yaml:<line>`, because line numbers go stale on any edit above them.
- `scripts/ci/yaml-citations.sh` enforces this in `ci-manifests-test.yml`: it fails on line-number citations and on citations whose file or anchor does not exist.
+70
View File
@@ -0,0 +1,70 @@
# homelab
GitOps source for the Renner homelab cluster. Flux applies `master` to
production, so every merge is a production change. Changes go in by pull
request only; see [CONTRIBUTING.md](CONTRIBUTING.md) for YAML conventions.
## Change rules that protect Home Assistant
Owner decision (REN-240, REN-243). Home Assistant runs the house, so it
gets two rules on top of normal review.
### 1. Disruptive work runs only 02:00–05:00 Europe/Berlin
Planned work that can restart Home Assistant or disrupt the cluster is
merged and applied only between **02:00 and 05:00 Europe/Berlin**. That
covers:
- node drain, node reboot, Talos upgrade
- CNI (Cilium, Multus) and cluster-wide network policy
- storage (Rook/Ceph, CSI, snapshot controller, CNPG operator)
- Flux core (`kubernetes/clusters/*/flux-system/`, Flux controllers)
- Authentik
- OpenBao, including secret rotation that restarts consumers
- anything in `kubernetes/apps/home-assistant/`
A PR in this list states in its description that it waits for the window.
Flux applies on merge, so "wait for the window" means **merge** in the
window, not just apply. If unsure whether a change is disruptive, treat it
as disruptive.
Not covered: Home Assistant image bumps by Flux image automation. They stay
fully automatic by owner decision. If one breaks Home Assistant, roll it
back with [RUNBOOK-home-assistant-image-rollback.md](kubernetes/RUNBOOK-home-assistant-image-rollback.md).
An incident rollback is not planned work; the owner decides its timing.
### 2. HA-impact review before merge
Every PR that touches `kubernetes/apps/home-assistant/`, or makes a
cluster-wide disruptive change from the list above, needs an **HA-impact
review** before merge: a named reviewer states in the PR what Home
Assistant will notice (restart, lost integration, lost history, none) and
approves.
- Reviewer: Hestia, the Home Assistant maintainer.
- Until Hestia exists: the owner does the HA-impact review.
This is in addition to the normal review and merge by Argus. Argus does
not merge such a PR without the HA-impact approval.
## Agent runtime images
Pod images for the Paperclip Kubernetes sandbox (REN-284). Each is the stock
`ghcr.io/paperclipai/agent-runtime-claude` (pinned by digest) plus a tool
set. Base user (1000, non-root), entrypoint and cmd are unchanged; the
images run with a read-only root FS. Source in `ci/images/agent-runtime-*`,
built by `.woodpecker/build-agent-runtime.yml` (re-run alone: deployment to
target `build-agent-runtime`), versions bumped by Renovate. Both also
carry `claude-agent-acp` for the ACP engine, pinned and patched like
Paperclip ships it, SDK override included
(`ci/images/agent-runtime-common/`); bump it by hand
together with Paperclip. All tools are on the default `PATH`.
| Image | `imageRegistry` | Adds |
|---|---|---|
| `gitea.renner.uno/konairius/agent-runtime-go/agent-runtime-claude:v1` | `gitea.renner.uno/konairius/agent-runtime-go` | Go toolchain, golangci-lint, govulncheck |
| `gitea.renner.uno/konairius/agent-runtime-ops/agent-runtime-claude:v1` | `gitea.renner.uno/konairius/agent-runtime-ops` | kubectl, flux, kustomize, helm |
The plugin keeps the name `agent-runtime-claude:v1` and swaps only host and
org, hence the nested path. Every build also pushes a date tag
(`:YYYY-MM-DD`) as the rollback point. `konairius` is public: no pull secret.
@@ -0,0 +1,66 @@
diff --git a/dist/acp-agent.js b/dist/acp-agent.js
index 0214a509eb5e7b777a69e4e34637941c275d27b1..403be02df66e25eee29e7d5bef14627011e02b30 100644
--- a/dist/acp-agent.js
+++ b/dist/acp-agent.js
@@ -2922,9 +2922,19 @@ export class ClaudeAcpAgent {
amount: message.total_cost_usd,
currency: "USD",
},
- ...(message.origin && {
- _meta: { "_claude/origin": message.origin },
- }),
+ _meta: {
+ ...(message.origin && { "_claude/origin": message.origin }),
+ // ACP's core Usage shape exposes context occupancy and
+ // cost, but not the billable input/output split. Keep the
+ // SDK's bounded aggregate in extension metadata so ACPX can
+ // normalize it without persisting a raw provider message.
+ usage: {
+ input_tokens: message.usage.input_tokens,
+ output_tokens: message.usage.output_tokens,
+ cache_read_input_tokens: message.usage.cache_read_input_tokens,
+ cache_creation_input_tokens: message.usage.cache_creation_input_tokens,
+ },
+ },
},
});
}
@@ -5311,6 +5321,10 @@ export class ClaudeAcpAgent {
settingSources: ["user", "project", "local"],
...(thinking !== undefined && { thinking }),
...userProvidedOptions,
+ // Paperclip Runner owns the complete session context. Its isolated
+ // user root contains only assigned skills; project/local settings
+ // would reintroduce host prompts, plugins, skills, and MCP servers.
+ ...(process.env.PAPERCLIP_ACPX_ISOLATED_CONTEXT === "1" && { settingSources: ["user"] }),
...(settings && { settings }),
env,
// Override certain fields that must be controlled by ACP
@@ -5318,7 +5332,9 @@ export class ClaudeAcpAgent {
includePartialMessages: true,
forwardSubagentText,
mcpServers: {
- ...(userProvidedOptions?.mcpServers || {}),
+ ...(process.env.PAPERCLIP_ACPX_ISOLATED_CONTEXT === "1"
+ ? {}
+ : (userProvidedOptions?.mcpServers || {})),
...mcpServers,
...(fileChangeAuditSupport
? { [FILE_CHANGE_AUDIT_SERVER_NAME]: fileChangeAuditSupport.mcpServer }
@@ -5329,6 +5345,16 @@ export class ClaudeAcpAgent {
allowDangerouslySkipPermissions: ALLOW_BYPASS,
permissionMode: initialPermissionMode,
canUseTool: this.canUseTool(sessionId),
+ // The runner pins this actual MCP endpoint before provider launch.
+ // Exempt only task delivery/control tools at the SDK dispatch boundary,
+ // not arbitrary provider permission metadata or MCP name prefixes.
+ ...(process.env.PAPERCLIP_ACPX_ISOLATED_CONTEXT === "1" && {
+ allowedTools: mcpServers.paperclip?.type === "http"
+ && mcpServers.paperclip.url === process.env.PAPERCLIP_ACPX_TASK_TOOL_BRIDGE_URL
+ ? ["paperclip_finish", "paperclip_block", "read_current_wake_comments", "request_human_input"]
+ .map((tool) => `mcp__paperclip__${tool}`)
+ : [],
+ }),
// Forward MCP elicitation requests onto ACP elicitation. Only attached
// when the client advertised support, so non-supporting clients keep the
// SDK's default (auto-decline) behavior. (AskUserQuestion is handled in
@@ -0,0 +1,9 @@
{
"private": true,
"dependencies": {
"@agentclientprotocol/claude-agent-acp": "0.73.0"
},
"overrides": {
"@anthropic-ai/claude-agent-sdk": "0.3.280"
}
}
+68
View File
@@ -0,0 +1,68 @@
# Paperclip agent runtime + Go toolchain (REN-284 / REN-286). Runs as the pod
# image of the `k8s-go` sandbox environment.
#
# Every tool comes from its upstream image, pinned by tag AND digest, so the
# dockerfile manager in Renovate bumps version and digest together. A curl +
# sha256 pin (as in ci/images/k8s) would break on every Renovate bump.
#
# Both binaries are static; they run on the Ubuntu 22.04 base unchanged.
FROM golang:1.27.1-bookworm@sha256:69a7b9788769bec032d238959b61854e9ae87f57be9029ec04e9885fabf99195 AS go
# govulncheck (REN-488) has no upstream image: build it in the go stage, static.
# The version pins the module; go verifies it against sum.golang.org. Renovate
# does not track it (no regex manager here): bump by hand.
FROM go AS govulncheck
RUN CGO_ENABLED=0 GOBIN=/out go install golang.org/x/vuln/cmd/govulncheck@v1.8.0
FROM golangci/golangci-lint:v2.14.0@sha256:ad862ba6b3798cbe0fd9fd7408d498fd74fbd2623a92406b2fd3898faf0bf98f AS golangci-lint
# upstream publishes no `v1` tag, only git-<sha> tags. Renovate keeps the
# digest current but cannot order commit tags; a newer base is a manual bump.
FROM ghcr.io/paperclipai/agent-runtime-claude:git-38d8f371722b315d2fb3bbaa512518742e33ce2f@sha256:33ad285f9476b8637d6d940c08d577797030125675bdf4f497a8ed1f79261c8b
COPY --from=go /usr/local/go /usr/local/go
COPY --from=golangci-lint /usr/bin/golangci-lint /usr/local/bin/golangci-lint
COPY --from=govulncheck /out/govulncheck /usr/local/bin/govulncheck
# go and gofmt also in /usr/local/bin: a process started with the default PATH
# (not the image ENV) still finds them.
USER root
RUN ln -s /usr/local/go/bin/go /usr/local/bin/go \
&& ln -s /usr/local/go/bin/gofmt /usr/local/bin/gofmt
USER 1000:1000
# ACP server the Paperclip ACP engine starts in the pod (REN-302). Version and
# patch match what Paperclip ships: packages/adapters/claude-local/package.json
# pins 0.73.0 and applies patches/@agentclientprotocol__claude-agent-acp@0.73.0.patch
# (isolated context, task-tool allow-list, usage metadata). Not bumped by
# Renovate on purpose: bump only together with Paperclip, and replace the patch.
# Paperclip also overrides the SDK (package.json pnpm overrides:
# claude-agent-sdk 0.3.280); a plain `npm install -g` ignores that and pulls an
# older SDK. So install from a package.json with the same override into a
# fixed prefix, and link the binary into /usr/local/bin.
COPY agent-runtime-common/claude-agent-acp.package.json /opt/claude-agent-acp/package.json
COPY agent-runtime-common/claude-agent-acp-0.73.0.patch /tmp/claude-agent-acp.patch
USER root
RUN cd /opt/claude-agent-acp \
&& npm install --omit=dev --no-audit --no-fund \
&& git -C node_modules/@agentclientprotocol/claude-agent-acp apply /tmp/claude-agent-acp.patch \
&& npm ls @anthropic-ai/claude-agent-sdk | grep -q 'claude-agent-sdk@0.3.280' \
&& ln -s /opt/claude-agent-acp/node_modules/.bin/claude-agent-acp /usr/local/bin/claude-agent-acp \
&& rm /tmp/claude-agent-acp.patch \
&& npm cache clean --force
USER 1000:1000
# The sandbox pod has a read-only root FS. Writable mounts: $HOME
# (/home/paperclip, 1Gi), $HOME/.cache (1Gi), /tmp (2Gi), /workspace.
# - GOPATH (module cache) goes to /tmp, the biggest one.
# - GOCACHE and the golangci-lint cache keep their default under $HOME/.cache.
# - GOTOOLCHAIN=local: a go.mod asking for a newer Go fails clearly instead of
# downloading a toolchain through the egress allow-list.
ENV PATH=/usr/local/go/bin:$PATH \
GOPATH=/tmp/go \
GOTOOLCHAIN=local
# Base user (1000:1000), entrypoint (tini) and cmd (agent shim) are inherited.
# The PATH check uses the base image's default PATH, not the ENV above.
RUN go version && golangci-lint version \
&& env -i PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin \
sh -ec 'for t in go gofmt golangci-lint govulncheck claude-agent-acp; do command -v "$t"; done'
+51
View File
@@ -0,0 +1,51 @@
# Paperclip agent runtime + cluster tools (REN-284 / REN-286). Runs as the pod
# image of the `k8s-ops` sandbox environment.
#
# Every tool comes from its upstream image, pinned by tag AND digest, so the
# dockerfile manager in Renovate bumps version and digest together. A curl +
# sha256 pin (as in ci/images/k8s) would break on every Renovate bump.
#
# kubectl and flux match the ci-k8s image. All four binaries are static; they
# run on the Ubuntu 22.04 base unchanged.
FROM registry.k8s.io/kubectl:v1.37.1@sha256:b7cab618e281b1ee7484e7b706a96e2135fbb6e072c2a573a7dab4e87d7f2385 AS kubectl
FROM ghcr.io/fluxcd/flux-cli:v2.9.6@sha256:b1ac18156f227af9a524b842a96f2c20986c7a779ef721df3ba4e4540f449d76 AS flux
FROM registry.k8s.io/kustomize/kustomize:v5.8.1@sha256:899fcd3bc898160e62bcaf82932b0cb29ba38d16272353db2e7acbba82129429 AS kustomize
FROM alpine/helm:4.3.0@sha256:a6cf54599ccb99d90cf0712b30f03fdb3cab062e6b94e0418cc4db7e8a1464b2 AS helm
# upstream publishes no `v1` tag, only git-<sha> tags. Renovate keeps the
# digest current but cannot order commit tags; a newer base is a manual bump.
FROM ghcr.io/paperclipai/agent-runtime-claude:git-38d8f371722b315d2fb3bbaa512518742e33ce2f@sha256:33ad285f9476b8637d6d940c08d577797030125675bdf4f497a8ed1f79261c8b
COPY --from=kubectl /bin/kubectl /usr/local/bin/kubectl
COPY --from=flux /usr/local/bin/flux /usr/local/bin/flux
COPY --from=kustomize /app/kustomize /usr/local/bin/kustomize
COPY --from=helm /usr/bin/helm /usr/local/bin/helm
# ACP server the Paperclip ACP engine starts in the pod (REN-302). Version and
# patch match what Paperclip ships: packages/adapters/claude-local/package.json
# pins 0.73.0 and applies patches/@agentclientprotocol__claude-agent-acp@0.73.0.patch
# (isolated context, task-tool allow-list, usage metadata). Not bumped by
# Renovate on purpose: bump only together with Paperclip, and replace the patch.
# Paperclip also overrides the SDK (package.json pnpm overrides:
# claude-agent-sdk 0.3.280); a plain `npm install -g` ignores that and pulls an
# older SDK. So install from a package.json with the same override into a
# fixed prefix, and link the binary into /usr/local/bin.
COPY agent-runtime-common/claude-agent-acp.package.json /opt/claude-agent-acp/package.json
COPY agent-runtime-common/claude-agent-acp-0.73.0.patch /tmp/claude-agent-acp.patch
USER root
RUN cd /opt/claude-agent-acp \
&& npm install --omit=dev --no-audit --no-fund \
&& git -C node_modules/@agentclientprotocol/claude-agent-acp apply /tmp/claude-agent-acp.patch \
&& npm ls @anthropic-ai/claude-agent-sdk | grep -q 'claude-agent-sdk@0.3.280' \
&& ln -s /opt/claude-agent-acp/node_modules/.bin/claude-agent-acp /usr/local/bin/claude-agent-acp \
&& rm /tmp/claude-agent-acp.patch \
&& npm cache clean --force
USER 1000:1000
# Read-only root FS: kubectl (~/.kube/cache) and helm (~/.cache, ~/.config)
# write only under $HOME, which the sandbox pod mounts writable. No ENV needed.
# Base user (1000:1000), entrypoint (tini) and cmd (agent shim) are inherited.
RUN kubectl version --client && flux version --client && kustomize version && helm version \
&& env -i PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin \
sh -ec 'for t in kubectl flux kustomize helm claude-agent-acp; do command -v "$t"; done'
+1 -1
View File
@@ -1,4 +1,4 @@
FROM alpine:3.21@sha256:48b0309ca019d89d40f670aa1bc06e426dc0931948452e8491e3d65087abc07d
FROM alpine:3.24@sha256:294b683cb724975bec92580e1e685676bd4b50bda910ddb8c51d4cabeaec77e6
# Alpine plus jq. Nothing application-specific — a general-purpose base for any
# workload that needs to read JSON from a shell script.
+1 -1
View File
@@ -1,4 +1,4 @@
FROM alpine:3.21@sha256:48b0309ca019d89d40f670aa1bc06e426dc0931948452e8491e3d65087abc07d
FROM alpine:3.24@sha256:294b683cb724975bec92580e1e685676bd4b50bda910ddb8c51d4cabeaec77e6
# Alpine plus the openssl CLI. Nothing application-specific — named for what it
# is, so anything needing `openssl s_client` / `x509` from a shell script can use
+1 -1
View File
@@ -1,4 +1,4 @@
FROM alpine:3.21@sha256:48b0309ca019d89d40f670aa1bc06e426dc0931948452e8491e3d65087abc07d
FROM alpine:3.24@sha256:294b683cb724975bec92580e1e685676bd4b50bda910ddb8c51d4cabeaec77e6
RUN apk add --no-cache \
ansible \
+1 -1
View File
@@ -1,4 +1,4 @@
FROM alpine:3.22@sha256:14358309a308569c32bdc37e2e0e9694be33a9d99e68afb0f5ff33cc1f695dce
FROM alpine:3.24@sha256:294b683cb724975bec92580e1e685676bd4b50bda910ddb8c51d4cabeaec77e6
# bird: BGP daemon for the pod-network mesh over pod0. Distro package, no build
# step — the image is the binary plus its runtime.
+1 -1
View File
@@ -1,4 +1,4 @@
FROM node:22-alpine@sha256:16e22a550f3863206a3f701448c45f7912c6896a62de43add43bb9c86130c3e2
FROM node:24-alpine@sha256:ebfe2f90462722a7a4de65e91990e97fe0d401c70e0e762c5b53302f905ec1c1
# Default to the latest Claude Code. Pinning a fixed version is the wrong
# default here: old releases eventually stop working against the API, so a
+4 -4
View File
@@ -28,10 +28,10 @@
# amd64 only, matching the ARCH the installer already hardcoded and the cluster's
# node architecture. Add a second stage if a different arch is ever needed.
FROM alpine:3.21@sha256:48b0309ca019d89d40f670aa1bc06e426dc0931948452e8491e3d65087abc07d AS fetch
FROM alpine:3.24@sha256:294b683cb724975bec92580e1e685676bd4b50bda910ddb8c51d4cabeaec77e6 AS fetch
ARG CNI_PLUGINS_VERSION=v1.5.1
ARG CNI_PLUGINS_SHA256=77baa2f669980a82255ffa2f2717de823992480271ee778aa51a9c60ae89ff9b
ARG CNI_PLUGINS_VERSION=v1.9.1
ARG CNI_PLUGINS_SHA256=b98f74a0f8522f0a83867178729c1aa70f2158f90c45a2ca8fa791db1c76b303
# busybox wget and tar are already in the base; nothing is installed here
# either. sha256sum -c fails the BUILD if the artifact does not match, which is
@@ -61,7 +61,7 @@ RUN set -eu; \
[ -x "/plugins/$p" ] || { echo "FATAL: /plugins/$p missing or not executable" >&2; exit 1; }; \
done
FROM alpine:3.21@sha256:48b0309ca019d89d40f670aa1bc06e426dc0931948452e8491e3d65087abc07d
FROM alpine:3.24@sha256:294b683cb724975bec92580e1e685676bd4b50bda910ddb8c51d4cabeaec77e6
# Alpine rather than scratch: the installer needs a shell to copy the binaries
# onto the host. busybox covers cp/mv/chown/ls, so nothing is added.
+2 -2
View File
@@ -23,7 +23,7 @@
# namespace, so can0 is only reachable with network_mode: host. That is also
# how the local MQTT broker on 127.0.0.1:1883 is reached. CAN_RAW sockets need
# no capabilities, so both run unprivileged.
FROM python:3.13-slim AS build
FROM python:3.14-slim@sha256:c3e521df8b2b498a7a682e7e18676771cb80c6b75b8699af886b2d554ce40151 AS build
# Pins live here, in the artifact, rather than in Ansible variables.
#
@@ -56,7 +56,7 @@ RUN git clone --quiet https://github.com/MyHomeMyData/E3onCAN.git /opt/e3oncan \
&& rm -rf /opt/e3oncan/.git
FROM python:3.13-slim
FROM python:3.14-slim@sha256:c3e521df8b2b498a7a682e7e18676771cb80c6b75b8699af886b2d554ce40151
ARG OPEN3E_REF=6553c10453a6bae1210908f38a5af2481a46a3e5
ARG E3ONCAN_REF=461dcbdf97e8d72d2edb9929c63b39382af6c3a1
+1 -1
View File
@@ -1,4 +1,4 @@
FROM alpine:3.21@sha256:48b0309ca019d89d40f670aa1bc06e426dc0931948452e8491e3d65087abc07d
FROM alpine:3.24@sha256:294b683cb724975bec92580e1e685676bd4b50bda910ddb8c51d4cabeaec77e6
ARG TALOS_VERSION=v1.13.10
ARG VELERO_VERSION=v1.16.0
+1 -1
View File
@@ -2,7 +2,7 @@
# domains -> TLS passthrough -> Traefik ClusterIP) from Ingresses carrying the
# public label. Standard library only, so the image is the interpreter plus one
# file; runs unprivileged as its own user.
FROM python:3.13-slim
FROM python:3.14-slim@sha256:c3e521df8b2b498a7a682e7e18676771cb80c6b75b8699af886b2d554ce40151
RUN useradd --system --no-create-home --shell /usr/sbin/nologin controller
COPY controller.py /opt/controller.py
+87
View File
@@ -0,0 +1,87 @@
# Paperclip server image (REN-401)
Upstream `paperclipai/paperclip` at the commit in `upstream.env`, plus every
`*.patch` in this directory. Built by `.woodpecker/build-paperclip.yml`,
pushed as `gitea.renner.uno/konairius/paperclip:build.<unix-ts>`, rolled out
by Flux image automation (`kubernetes/infrastructure/image-automation/paperclip.yaml`).
## Why
k8s sandbox runs fail: the run path never sets the lease `remoteCwd`, so file
sync into the pod fails (paperclipai/paperclip#13864). The fix is
paperclipai/paperclip#13733, open and not merged.
`pr-13733-lease-remote-cwd.patch` is that PR's diff (head `5f320bf6`).
#13733 covers only the run path. Adapter environment tests (binding an agent
to a k8s environment) sync managed config before any workspace is realized,
so the lease still has no `remoteCwd` and the Claude test fails with
`claude_managed_config_dir_failed` (REN-409). The fix is
paperclipai/paperclip#14769, also open: the plugin sets `remoteCwd:
/workspace` when it acquires or resumes a lease.
`pr-14769-probe-remote-cwd.patch` is that PR's diff (head `10dc7371`).
Claude auto memory is lost after every run (REN-541): it lives under
`CLAUDE_CONFIG_DIR`, which Paperclip makes fresh per run and deletes.
`ren-541-claude-auto-memory.patch` makes the ACPX engine write
`autoMemoryDirectory: <AGENT_HOME>/memory` into the per-run
`.claude/settings.local.json`. `AGENT_HOME` is restored before and saved after
every run, local and in k8s pods. The value is not part of the session
fingerprint, so resume is unchanged. No upstream PR yet; rename the patch to
`pr-<n>-…` once there is one.
Claude sessions never resume with a managed AI connection (REN-563): the
server gives every run a fresh temp home (`HOME`, `XDG_*`,
`CLAUDE_CONFIG_DIR`, …) and deletes it after the run.
`ren-563-acpx-claude-session-resume.patch` fixes both halves for local runs:
the ACPX engine hashes a fixed placeholder for those paths in the session
fingerprint (`adapterEnvHash`), as the server's own fingerprint already does,
and links `CLAUDE_CONFIG_DIR/projects` (the Claude transcripts) to
`<stateDir>/claude-projects`, which persists. Both must ship together: a
stable fingerprint without the transcript makes the resumed turn fail with
"Resource not found" (homelab#1111, reverted in #1113). Remote runs are
unchanged. No upstream PR yet.
A cancelled or failed k8s pod run blocks its card for good (REN-841). The
owner's next comment waits on `remote_cleanup`, because the server continues
only when every remote lease carries a provider termination receipt
(`explicit-native-continuation.ts`), and the Kubernetes plugin's
`onEnvironmentReleaseLease` / `onEnvironmentDestroyLease` returned `void`.
`ren-841-k8s-termination-receipt.patch` makes both return
`{ providerLeaseId, state: "destroyed" }`, but only after the Sandbox CR or
Job (and, on destroy, the pod) reads 404, polling for up to 20 s, below the
server's 30 s plugin RPC timeout. If that check times out or fails, the hook
returns no receipt, as before. No upstream PR yet.
## Files
- `upstream.env` — pinned commit and the version string stamped into the
image. Bump both together.
- `prepare.sh` — fetches the commit, applies the patches, writes
`Dockerfile.kaniko` (upstream's `COPY --parents` line split into plain
`COPY` lines; kaniko does not support `--parents`), and adds the build of
the Kubernetes sandbox provider plugin to the `build` stage (REN-405):
upstream's `production` target ships only its source, so the plugin fails
with "no longer exposes a Paperclip manifest". The build fails if
`dist/manifest.js` is missing.
- `*.patch` — applied in name order with `git apply`.
## Moving to a newer upstream commit
Set `PAPERCLIP_COMMIT` to the new master commit and `PAPERCLIP_VERSION` to
`git describe --tags --match 'v*' --long <commit>`, then run
`sh prepare.sh /tmp/src`: it fails if a patch no longer applies.
## Exit: when every patch here is merged upstream
Renovate cannot watch an upstream PR, so this is a manual step. Once
upstream nightly contains all of them:
1. `kubernetes/infrastructure/image-automation/paperclip.yaml`: back to
`ghcr.io/paperclipai/paperclip` with `filterTags.pattern: '^nightly$'`
(the version before REN-401 in git history).
2. `renovate.json`: swap `gitea.renner.uno/konairius/paperclip` back to
`ghcr.io/paperclipai/paperclip` in the image-automation exclusion list.
3. Delete this directory and `.woodpecker/build-paperclip.yml`.
Image automation then rewrites `kubernetes/apps/paperclip/paperclip.yaml`
to the nightly digest by itself.
@@ -0,0 +1,93 @@
diff --git a/server/src/__tests__/environment-run-orchestrator.test.ts b/server/src/__tests__/environment-run-orchestrator.test.ts
index f3d1fc659..812cae357 100644
--- a/server/src/__tests__/environment-run-orchestrator.test.ts
+++ b/server/src/__tests__/environment-run-orchestrator.test.ts
@@ -430,6 +430,51 @@ describe("environmentRunOrchestrator — realizeForRun", () => {
expect(result.persistedExecutionWorkspace).toEqual(updatedEw);
});
+ it("persists the realized cwd as remoteCwd when realization returns no workspaceRealization payload", async () => {
+ const runtime = makeMockRuntime({
+ realizeWorkspace: vi.fn().mockResolvedValue({
+ cwd: "/workspace",
+ metadata: { provider: "kubernetes", remoteCwd: "/workspace" },
+ }),
+ } as Partial<EnvironmentRuntimeService>);
+ mockResolveEnvironmentExecutionTarget.mockResolvedValue({ kind: "local", environmentId: "env-1", leaseId: "lease-1" });
+
+ const orchestrator = environmentRunOrchestrator(mockDb, { environmentRuntime: runtime });
+
+ await orchestrator.realizeForRun(
+ makeRealizeInput({ environment: makeEnvironment("sandbox") }),
+ );
+
+ expect(mockUpdateLeaseMetadata).toHaveBeenCalledWith(
+ "lease-1",
+ expect.objectContaining({ remoteCwd: "/workspace" }),
+ );
+ // Nothing to record about the realization shape, so the execution workspace
+ // row is left untouched.
+ expect(mockUpdateExecutionWorkspace).not.toHaveBeenCalled();
+ });
+
+ it("does not rewrite lease metadata when the realized cwd already matches the lease", async () => {
+ const runtime = makeMockRuntime({
+ realizeWorkspace: vi.fn().mockResolvedValue({
+ cwd: "/workspace",
+ metadata: { provider: "kubernetes", remoteCwd: "/workspace" },
+ }),
+ } as Partial<EnvironmentRuntimeService>);
+ mockResolveEnvironmentExecutionTarget.mockResolvedValue({ kind: "local", environmentId: "env-1", leaseId: "lease-1" });
+
+ const orchestrator = environmentRunOrchestrator(mockDb, { environmentRuntime: runtime });
+
+ await orchestrator.realizeForRun(
+ makeRealizeInput({
+ environment: makeEnvironment("sandbox"),
+ lease: makeLease({ metadata: { remoteCwd: "/workspace" } }),
+ }),
+ );
+
+ expect(mockUpdateLeaseMetadata).not.toHaveBeenCalled();
+ });
+
it("runs a remote provision command after workspace realization when configured", async () => {
mockBuildWorkspaceRealizationRequest.mockReturnValue({
version: 1,
diff --git a/server/src/services/environment-run-orchestrator.ts b/server/src/services/environment-run-orchestrator.ts
index 97cca667e..e76f64913 100644
--- a/server/src/services/environment-run-orchestrator.ts
+++ b/server/src/services/environment-run-orchestrator.ts
@@ -485,16 +485,29 @@ export function environmentRunOrchestrator(
}
// Step 3: Persist realization metadata on lease and execution workspace
- if (Object.keys(workspaceRealization).length > 0) {
+ const hasWorkspaceRealization = Object.keys(workspaceRealization).length > 0;
+ // A driver that realizes the workspace reports the directory it prepared
+ // through the realization `cwd`. Persist it on the lease as `remoteCwd`, so
+ // every later step that receives only the lease — native file sync, a
+ // resumed lease, a second run against the same lease — confines itself to
+ // the same root. Without it a driver whose realization returns no
+ // `workspaceRealization` payload leaves the lease without a root at all,
+ // and the sync step fails even though realization succeeded.
+ const currentRemoteCwd =
+ typeof lease.metadata?.remoteCwd === "string" ? lease.metadata.remoteCwd.trim() : "";
+ const realizedRemoteCwd =
+ realizedWorkspaceCwd && realizedWorkspaceCwd !== currentRemoteCwd ? realizedWorkspaceCwd : null;
+ if (hasWorkspaceRealization || realizedRemoteCwd) {
const nextLeaseMetadata = {
...(lease.metadata ?? {}),
- workspaceRealization,
+ ...(hasWorkspaceRealization ? { workspaceRealization } : {}),
+ ...(realizedRemoteCwd ? { remoteCwd: realizedRemoteCwd } : {}),
};
const updatedLease = await environmentsSvc.updateLeaseMetadata(lease.id, nextLeaseMetadata);
if (updatedLease) {
lease = updatedLease;
}
- if (persistedExecutionWorkspace) {
+ if (hasWorkspaceRealization && persistedExecutionWorkspace) {
const updatedEw = await executionWorkspacesSvc.update(persistedExecutionWorkspace.id, {
metadata: {
...(persistedExecutionWorkspace.metadata ?? {}),
@@ -0,0 +1,86 @@
diff --git a/packages/plugins/sandbox-providers/kubernetes/README.md b/packages/plugins/sandbox-providers/kubernetes/README.md
index a51c6ecee60e..72618cb11296 100644
--- a/packages/plugins/sandbox-providers/kubernetes/README.md
+++ b/packages/plugins/sandbox-providers/kubernetes/README.md
@@ -140,6 +140,8 @@ Every agent pod is:
Plus per-namespace `pod-security.kubernetes.io/enforce: restricted` and a deny-all NetworkPolicy baseline with explicit egress allow-list (DNS, paperclip-server, configured FQDNs/CIDRs).
+The lease starts with `/workspace` as the native file-sync confinement root. Adapter environment tests can upload managed config before the server realizes a workspace. When resuming a lease, the provider keeps a previously recorded `remoteCwd` so a custom realized workspace is not replaced with the default.
+
The per-run Secret carrying the bootstrap token and adapter API keys has `ownerReferences` pointing at the owning Job, so a single `kubectl delete job …` cascades cleanly to the Pod and Secret.
## Optional Kata-FC microVM isolation
diff --git a/packages/plugins/sandbox-providers/kubernetes/src/plugin.ts b/packages/plugins/sandbox-providers/kubernetes/src/plugin.ts
index 8ae47de8ecac..98016385da05 100644
--- a/packages/plugins/sandbox-providers/kubernetes/src/plugin.ts
+++ b/packages/plugins/sandbox-providers/kubernetes/src/plugin.ts
@@ -454,6 +454,9 @@ const plugin = definePlugin({
secretName,
phase: "Pending",
backend: config.backend,
+ // Adapter environment probes sync managed assets before workspace
+ // realization. Give native sync the pod's mounted confinement root now.
+ remoteCwd: "/workspace",
scopedNetworkPolicyName,
scopedNetworkEgress,
// Native file sync streams over a pod exec; only the sandbox-cr backend
@@ -529,6 +532,10 @@ const plugin = definePlugin({
secretName,
phase: check.phase,
backend: leaseBackend,
+ remoteCwd:
+ typeof params.leaseMetadata?.remoteCwd === "string" && params.leaseMetadata.remoteCwd.trim()
+ ? params.leaseMetadata.remoteCwd.trim()
+ : "/workspace",
scopedNetworkPolicyName:
typeof params.leaseMetadata?.scopedNetworkPolicyName === "string"
? params.leaseMetadata.scopedNetworkPolicyName
diff --git a/packages/plugins/sandbox-providers/kubernetes/src/types.ts b/packages/plugins/sandbox-providers/kubernetes/src/types.ts
index 5626daa93846..ef3d0d889a4c 100644
--- a/packages/plugins/sandbox-providers/kubernetes/src/types.ts
+++ b/packages/plugins/sandbox-providers/kubernetes/src/types.ts
@@ -90,6 +90,8 @@ export interface KubernetesLeaseMetadata {
phase: "Pending" | "Running" | "Succeeded" | "Failed";
/** Which backend provisioned this lease. */
backend: "sandbox-cr" | "job";
+ /** Native sync confinement root; present before workspace realization for probes. */
+ remoteCwd: string;
scopedNetworkPolicyName: string | null;
scopedNetworkEgress: {
allowFqdns: string[];
diff --git a/packages/plugins/sandbox-providers/kubernetes/test/unit/plugin-lease-lifecycle.test.ts b/packages/plugins/sandbox-providers/kubernetes/test/unit/plugin-lease-lifecycle.test.ts
index 7ad0ca4807e5..4c23410d4d15 100644
--- a/packages/plugins/sandbox-providers/kubernetes/test/unit/plugin-lease-lifecycle.test.ts
+++ b/packages/plugins/sandbox-providers/kubernetes/test/unit/plugin-lease-lifecycle.test.ts
@@ -80,6 +80,7 @@ describe("onEnvironmentResumeLease", () => {
secretName: "pc-abc-env",
phase: "Running",
backend: "sandbox-cr",
+ remoteCwd: "/workspace",
resumedLease: true,
// sandbox-cr has a pod-exec channel, so native file sync stays enabled.
nativeFileSyncUnsupported: false,
@@ -87,6 +88,22 @@ describe("onEnvironmentResumeLease", () => {
);
});
+ it("keeps a custom realized cwd when resuming a sandbox lease", async () => {
+ h.clients = {
+ custom: { getNamespacedCustomObject: vi.fn().mockResolvedValue(readySandboxCr("pc-abc-pod")) },
+ core: { readNamespacedPod: vi.fn().mockResolvedValue({ status: { phase: "Running" } }) },
+ };
+ const lease = await plugin.definition.onEnvironmentResumeLease!({
+ driverKey: "kubernetes",
+ companyId: "acme",
+ environmentId: "env-1",
+ config: CONFIG,
+ providerLeaseId: "pc-abc",
+ leaseMetadata: leaseMetadata({ remoteCwd: "/workspace/custom" }),
+ });
+ expect(lease.metadata?.remoteCwd).toBe("/workspace/custom");
+ });
+
it("flags a resumed job-backend lease as native-sync-unsupported so the server keeps the base64 fallback", async () => {
h.clients = {
batch: {
+59
View File
@@ -0,0 +1,59 @@
#!/bin/sh
# Fetch upstream Paperclip at the pinned commit, apply our patches and make
# the Dockerfile buildable with kaniko. Usage: prepare.sh <target-dir>
set -eu
HERE=$(cd "$(dirname "$0")" && pwd)
. "$HERE/upstream.env"
OUT=$1
rm -rf "$OUT"
git init -q "$OUT"
cd "$OUT"
git fetch -q --depth 1 https://github.com/paperclipai/paperclip.git "$PAPERCLIP_COMMIT"
git -c advice.detachedHead=false checkout -q FETCH_HEAD
test "$(git rev-parse HEAD)" = "$PAPERCLIP_COMMIT"
for p in "$HERE"/*.patch; do
echo "applying $(basename "$p")"
git apply "$p"
done
# kaniko does not know `COPY --parents` (BuildKit only). Upstream uses it for
# one line: every sandbox provider's package.json. Replace it with one plain
# COPY per provider directory, which copies the same files to the same place.
grep -c -- '^COPY --parents packages/plugins/sandbox-providers/\./\*/package.json packages/plugins/sandbox-providers/$' Dockerfile | grep -qx 1
awk '
/^COPY --parents packages\/plugins\/sandbox-providers\// {
while (("ls -d packages/plugins/sandbox-providers/*/package.json" | getline f) > 0) {
d = f; sub(/package.json$/, "", d)
print "COPY " f " " d
}
next
}
{ print }
' Dockerfile > Dockerfile.kaniko
if grep -q -- '--parents' Dockerfile.kaniko; then
echo "Dockerfile.kaniko still uses COPY --parents" >&2
exit 1
fi
# Build the Kubernetes sandbox provider into the image (REN-405). Upstream's
# `production` target ships only its source; the plugin loader needs
# dist/manifest.js. Same commands as upstream's `cloud-plugins` stage, run in
# the `build` stage right after the server build, so production's
# `COPY --from=build /app /app` carries dist/ and node_modules along. No extra
# stage: kaniko would snapshot the whole build stage again for it.
export ANCHOR='RUN test -f server/dist/index.js || (echo "ERROR: server build output missing" && exit 1)'
grep -c -F -x -- "$ANCHOR" Dockerfile.kaniko | grep -qx 1
K=packages/plugins/sandbox-providers/kubernetes
awk -v k="$K" '
{ print }
$0 == ENVIRON["ANCHOR"] {
print "RUN pnpm -C " k " install --ignore-workspace --no-lockfile \\"
print " && pnpm -C " k " build \\"
print " && test -f " k "/dist/manifest.js"
}
' Dockerfile.kaniko > Dockerfile.kaniko.new
mv Dockerfile.kaniko.new Dockerfile.kaniko
grep -q -- "test -f $K/dist/manifest.js" Dockerfile.kaniko
rm -rf .git
@@ -0,0 +1,118 @@
diff --git a/packages/adapter-utils/src/acpx-engine/execute.test.ts b/packages/adapter-utils/src/acpx-engine/execute.test.ts
index a26f980..112e2eb 100644
--- a/packages/adapter-utils/src/acpx-engine/execute.test.ts
+++ b/packages/adapter-utils/src/acpx-engine/execute.test.ts
@@ -2544,6 +2544,37 @@ describe("shared ACPX engine runtime behavior", () => {
expect(note).toBeTruthy();
});
+ it("points Claude auto memory at the run's AGENT_HOME without changing the session fingerprint", async () => {
+ const root = await makeTempRoot();
+ const stateDir = path.join(root, "state");
+ const cwd = path.join(root, "worktree");
+ await fs.mkdir(cwd, { recursive: true });
+ const stableHome = path.join(root, "agent-home");
+ const runAgentHome = (runId: string) => path.join(root, "file-sync", "runs", runId, "live");
+ const readSettings = async () =>
+ JSON.parse(await fs.readFile(path.join(cwd, ".claude", "settings.local.json"), "utf8")) as {
+ autoMemoryDirectory?: string;
+ permissions?: { additionalDirectories?: string[] };
+ };
+
+ const first = await runExecutor(
+ { agent: "claude", stateDir, cwd },
+ { context: { paperclipWorkspace: { cwd, agentHome: runAgentHome("a"), agentHomeForPermissions: stableHome } } },
+ );
+ expect((await readSettings()).autoMemoryDirectory).toBe(path.join(runAgentHome("a"), "memory"));
+
+ const second = await runExecutor(
+ { agent: "claude", stateDir, cwd },
+ { context: { paperclipWorkspace: { cwd, agentHome: runAgentHome("b"), agentHomeForPermissions: stableHome } } },
+ );
+ const written = await readSettings();
+ expect(written.autoMemoryDirectory).toBe(path.join(runAgentHome("b"), "memory"));
+ expect(written.permissions?.additionalDirectories).toContain(stableHome);
+ expect(written.permissions?.additionalDirectories).not.toContain(runAgentHome("b"));
+ expect(second.result.sessionParams?.configFingerprint).toBeTypeOf("string");
+ expect(second.result.sessionParams?.configFingerprint).toBe(first.result.sessionParams?.configFingerprint);
+ });
+
it("merges Paperclip allowlist into an existing .claude/settings.local.json without losing user entries", async () => {
const root = await makeTempRoot();
const stateDir = path.join(root, "state");
diff --git a/packages/adapter-utils/src/acpx-engine/execute.ts b/packages/adapter-utils/src/acpx-engine/execute.ts
index b1dc569..e5681b8 100644
--- a/packages/adapter-utils/src/acpx-engine/execute.ts
+++ b/packages/adapter-utils/src/acpx-engine/execute.ts
@@ -1558,6 +1558,7 @@ interface PaperclipClaudeSettingsResult {
additionalDirectories: string[];
defaultMode: string;
overrodeDontAsk: boolean;
+ autoMemoryDirectory: string | null;
}
function uniqueSorted(values: Array<string | null | undefined>): string[] {
@@ -1571,10 +1572,19 @@ function uniqueSorted(values: Array<string | null | undefined>): string[] {
// denies every non-allowlisted tool and never reaches `canUseTool`), and we
// widen the SDK's Read sandbox to include the Paperclip state dirs the agent
// needs to talk to its own control plane.
+//
+// It also points Claude's auto memory at `<AGENT_HOME>/memory`. The default
+// location lives under CLAUDE_CONFIG_DIR, which is a per-run temp home, so
+// memories were lost after every run. AGENT_HOME is restored before and saved
+// after each run, locally and in remote sandboxes. Claude ignores
+// `autoMemoryDirectory` only in checked-in project settings, not local ones.
async function writePaperclipClaudeSettings(input: {
cwd: string;
stateDir: string;
agentHome: string;
+ // The run's actual AGENT_HOME (the in-sandbox path for remote runs). It may
+ // differ from `agentHome`, which stays stable for session identity.
+ runAgentHome: string;
companyId: string;
}): Promise<PaperclipClaudeSettingsResult> {
const filePath = path.join(input.cwd, ".claude", "settings.local.json");
@@ -1630,7 +1640,14 @@ async function writePaperclipClaudeSettings(input: {
additionalDirectories: mergedAdditionalDirectories,
defaultMode,
};
- const next: Record<string, unknown> = { ...existing, permissions: nextPermissions };
+ const autoMemoryDirectory = input.runAgentHome
+ ? path.posix.join(input.runAgentHome, "memory")
+ : null;
+ const next: Record<string, unknown> = {
+ ...existing,
+ permissions: nextPermissions,
+ ...(autoMemoryDirectory ? { autoMemoryDirectory } : {}),
+ };
await writeFileAtomically({
target: filePath,
contents: `${JSON.stringify(next, null, 2)}\n`,
@@ -1642,6 +1659,7 @@ async function writePaperclipClaudeSettings(input: {
additionalDirectories: mergedAdditionalDirectories,
defaultMode,
overrodeDontAsk,
+ autoMemoryDirectory,
};
}
@@ -2064,12 +2082,18 @@ async function buildRuntime(input: {
// by the company root already granted in these settings; the process env
// still receives this run's actual AGENT_HOME.
agentHome: asString(workspaceContext.agentHomeForPermissions, agentHome),
+ // Auto memory follows the actual AGENT_HOME so it is saved with the run.
+ // It is not part of the session fingerprint: a moved memory directory
+ // must not invalidate a resumable conversation.
+ runAgentHome: agentHome,
companyId: agent.companyId,
});
skillCommandNotes.push(
`Wrote Paperclip-managed Claude settings to ${paperclipClaudeSettings.filePath} (defaultMode=${paperclipClaudeSettings.defaultMode}${
paperclipClaudeSettings.overrodeDontAsk ? "; overrode user dontAsk" : ""
- }, +${paperclipClaudeSettings.additionalDirectories.length} read root(s), +${paperclipClaudeSettings.allow.length} allow rule(s)).`,
+ }, +${paperclipClaudeSettings.additionalDirectories.length} read root(s), +${paperclipClaudeSettings.allow.length} allow rule(s)${
+ paperclipClaudeSettings.autoMemoryDirectory ? `, autoMemoryDirectory=${paperclipClaudeSettings.autoMemoryDirectory}` : ""
+ }).`,
);
} else if (acpxAgent === "codex") {
// Step 2 — codex-home.seed: the codex managed-home + skills preparation.
@@ -0,0 +1,128 @@
diff --git a/packages/adapter-utils/src/acpx-engine/execute.test.ts b/packages/adapter-utils/src/acpx-engine/execute.test.ts
index 112e2eb..004baf0 100644
--- a/packages/adapter-utils/src/acpx-engine/execute.test.ts
+++ b/packages/adapter-utils/src/acpx-engine/execute.test.ts
@@ -1857,6 +1857,45 @@ describe("shared ACPX engine runtime behavior", () => {
expect(changed.result.sessionParams?.configFingerprint).not.toBe(first.result.sessionParams?.configFingerprint);
});
+ it("keeps the per-run managed AI home out of session identity and keeps Claude transcripts", async () => {
+ const root = await makeTempRoot();
+ const stateDir = path.join(root, "state");
+ const config = { agentCommand: "node ./fake-acp.js", stateDir };
+ async function withManagedHome(home: string, claudeConfigDir = path.join(home, "provider")) {
+ return runExecutor({
+ ...config,
+ managedAiConnection: { identity: "grant-1:shared:abc" },
+ env: {
+ HOME: home,
+ XDG_CONFIG_HOME: path.join(home, "config"),
+ XDG_DATA_HOME: path.join(home, "data"),
+ CODEX_HOME: path.join(home, "provider"),
+ GROK_HOME: path.join(home, "provider"),
+ CLAUDE_CONFIG_DIR: claudeConfigDir,
+ },
+ }, { context: { taskId: "issue-1" } });
+ }
+ const fp = (run: Awaited<ReturnType<typeof runExecutor>>) => run.result.sessionParams?.configFingerprint;
+ const first = await withManagedHome(path.join(root, "paperclip-ai-a"));
+ const second = await withManagedHome(path.join(root, "paperclip-ai-b"));
+ const overridden = await withManagedHome(path.join(root, "paperclip-ai-c"), path.join(root, "custom-claude"));
+ expect(fp(first)).toBeTypeOf("string");
+ expect(fp(second)).toBe(fp(first));
+ expect(fp(overridden)).not.toBe(fp(first));
+
+ // The transcript dir of each managed home points at one dir in the state
+ // dir, so a resumed session finds its transcript after the home is deleted.
+ const transcripts = path.join(stateDir, "claude-projects");
+ expect(await fs.readlink(path.join(root, "paperclip-ai-a", "provider", "projects"))).toBe(transcripts);
+ expect(await fs.readlink(path.join(root, "paperclip-ai-b", "provider", "projects"))).toBe(transcripts);
+ await expect(fs.lstat(path.join(root, "custom-claude", "projects"))).rejects.toThrow();
+
+ // Without a managed AI connection the same paths are user config and still count.
+ const plainA = await runExecutor({ ...config, env: { HOME: path.join(root, "home-a") } }, { context: { taskId: "issue-1" } });
+ const plainB = await runExecutor({ ...config, env: { HOME: path.join(root, "home-b") } }, { context: { taskId: "issue-1" } });
+ expect(fp(plainB)).not.toBe(fp(plainA));
+ });
+
it("busts the session fingerprint when a stable configured PAPERCLIP_* value rotates", async () => {
const root = await makeTempRoot();
const stateDir = path.join(root, "state");
diff --git a/packages/adapter-utils/src/acpx-engine/execute.ts b/packages/adapter-utils/src/acpx-engine/execute.ts
index e5681b8..0fd486c 100644
--- a/packages/adapter-utils/src/acpx-engine/execute.ts
+++ b/packages/adapter-utils/src/acpx-engine/execute.ts
@@ -1663,6 +1663,26 @@ async function writePaperclipClaudeSettings(input: {
};
}
+// Claude keeps conversation transcripts in CLAUDE_CONFIG_DIR/projects. A
+// managed AI home is a per-run temp dir that the server deletes after the run,
+// so the next run could not resume ("Resource not found"). Point `projects` at
+// a directory in the agent's state dir, like ~/.claude/projects on a normal
+// install. The server's recursive cleanup removes the link, not its target.
+async function linkManagedClaudeTranscripts(input: {
+ claudeConfigDir: string;
+ stateDir: string;
+}): Promise<string> {
+ const target = path.join(input.stateDir, "claude-projects");
+ await fs.mkdir(input.claudeConfigDir, { recursive: true, mode: 0o700 });
+ await fs.mkdir(target, { recursive: true, mode: 0o700 });
+ const link = path.join(input.claudeConfigDir, "projects");
+ const current = await fs.readlink(link).catch(() => null);
+ if (current === target) return target;
+ await fs.rm(link, { recursive: true, force: true });
+ await fs.symlink(target, link, "dir");
+ return target;
+}
+
// Cross the CLI's staging seam for a runner-backed remote sandbox: ship the
// workspace (and, in PR 2, the per-adapter managed-home `assets`) into the
// sandbox and obtain the in-sandbox `workspaceRemoteDir` plus the non-null
@@ -2027,6 +2047,30 @@ async function buildRuntime(input: {
// are absent from tempKeysApplied and keep their compatibility protection.
if (!scratchKeys.has(key) || value !== scratch.dir) resolvedAdapterEnv[key] = value;
}
+ // A managed AI connection gets a fresh server-made temp home on every run
+ // (HOME, XDG_*, and the provider home under it). Hash a fixed placeholder for
+ // those paths so the session can resume; the server's own fingerprint does
+ // the same (managedAiSessionFingerprintConfig). Values that differ from the
+ // managed layout are real overrides and stay in the hash. A Claude session
+ // can only resume if its transcript survives the run, so this pairs with
+ // linkManagedClaudeTranscripts below. Remote runs keep their transcript in
+ // the sandbox and are left as they are.
+ const managedHome = config.managedAiConnection && !executionTargetIsRemote ? resolvedAdapterEnv.HOME : undefined;
+ if (managedHome) {
+ const managedLayout: Record<string, string> = {
+ HOME: "",
+ XDG_CONFIG_HOME: "config",
+ XDG_DATA_HOME: "data",
+ CODEX_HOME: "provider",
+ GROK_HOME: "provider",
+ CLAUDE_CONFIG_DIR: "provider",
+ };
+ for (const [key, sub] of Object.entries(managedLayout)) {
+ if (resolvedAdapterEnv[key] === (sub ? path.join(managedHome, sub) : managedHome)) {
+ resolvedAdapterEnv[key] = sub ? `<managed-ai-home>/${sub}` : "<managed-ai-home>";
+ }
+ }
+ }
if (authToken) env.PAPERCLIP_API_KEY = authToken;
// For the claude agent, set model via ANTHROPIC_MODEL at startup rather than
// via session/set_config_option — the ACP server's set_config_option handler
@@ -2088,6 +2132,15 @@ async function buildRuntime(input: {
runAgentHome: agentHome,
companyId: agent.companyId,
});
+ // Same condition as the fingerprint placeholder above: a resumable session
+ // must find its transcript in the next run's managed home.
+ if (resolvedAdapterEnv.CLAUDE_CONFIG_DIR === "<managed-ai-home>/provider" && env.CLAUDE_CONFIG_DIR) {
+ const transcriptsDir = await linkManagedClaudeTranscripts({
+ claudeConfigDir: env.CLAUDE_CONFIG_DIR,
+ stateDir,
+ });
+ skillCommandNotes.push(`Linked Claude transcripts to ${transcriptsDir}.`);
+ }
skillCommandNotes.push(
`Wrote Paperclip-managed Claude settings to ${paperclipClaudeSettings.filePath} (defaultMode=${paperclipClaudeSettings.defaultMode}${
paperclipClaudeSettings.overrodeDontAsk ? "; overrode user dontAsk" : ""
@@ -0,0 +1,384 @@
diff --git a/packages/plugins/sandbox-providers/kubernetes/src/lease-lifecycle.ts b/packages/plugins/sandbox-providers/kubernetes/src/lease-lifecycle.ts
index 87e18ae..2224e60 100644
--- a/packages/plugins/sandbox-providers/kubernetes/src/lease-lifecycle.ts
+++ b/packages/plugins/sandbox-providers/kubernetes/src/lease-lifecycle.ts
@@ -21,6 +21,7 @@ import { deleteJob, findPodForJob, getJobStatus } from "./job-orchestrator.js";
import {
deleteSandboxCr,
findPodForSandbox,
+ getSandboxCrStatus,
waitForSandboxReady,
} from "./sandbox-cr-orchestrator.js";
@@ -191,3 +192,60 @@ export async function destroyLeaseResources(
);
}
}
+
+export interface WorkloadGoneInput {
+ namespace: string;
+ /** Workload resource name (Sandbox CR name or Job name) == providerLeaseId. */
+ name: string;
+ backend: "sandbox-cr" | "job";
+ podName?: string | null;
+ /** Stays below the server's 30 s default plugin RPC timeout. */
+ timeoutMs?: number;
+ pollMs?: number;
+}
+
+/**
+ * Poll until the workload (and the named pod, if any) returns 404. Deletes use
+ * Foreground propagation, so the workload disappears only after its pod is
+ * gone. True is the evidence behind a `destroyed` termination receipt; false
+ * (still present at the deadline, or a read failed) means the caller must not
+ * claim one. Never throws: the delete itself already succeeded.
+ */
+export async function waitForWorkloadGone(
+ clients: KubeClients,
+ input: WorkloadGoneInput,
+): Promise<boolean> {
+ const deadline = Date.now() + (input.timeoutMs ?? 20_000);
+ const pollMs = input.pollMs ?? 500;
+ const gone = async (read: () => Promise<unknown>): Promise<boolean> => {
+ try {
+ await read();
+ return false;
+ } catch (err) {
+ if (isKubeNotFoundError(err)) return true;
+ throw err;
+ }
+ };
+ try {
+ return await pollUntilGone();
+ } catch {
+ return false;
+ }
+
+ async function pollUntilGone(): Promise<boolean> {
+ for (;;) {
+ const workloadGone = await gone(() =>
+ input.backend === "sandbox-cr"
+ ? getSandboxCrStatus(clients, input.namespace, input.name)
+ : getJobStatus(clients, input.namespace, input.name),
+ );
+ const podName = input.podName;
+ const podGone = !podName || await gone(() =>
+ clients.core.readNamespacedPod({ namespace: input.namespace, name: podName }),
+ );
+ if (workloadGone && podGone) return true;
+ if (Date.now() >= deadline) return false;
+ await new Promise((resolve) => setTimeout(resolve, pollMs));
+ }
+ }
+}
diff --git a/packages/plugins/sandbox-providers/kubernetes/src/plugin.ts b/packages/plugins/sandbox-providers/kubernetes/src/plugin.ts
index 9801638..bf5ce0a 100644
--- a/packages/plugins/sandbox-providers/kubernetes/src/plugin.ts
+++ b/packages/plugins/sandbox-providers/kubernetes/src/plugin.ts
@@ -15,6 +15,7 @@ import type {
PluginEnvironmentSyncInParams,
PluginEnvironmentSyncOutParams,
PluginEnvironmentSyncResult,
+ PluginEnvironmentTerminationReceipt,
PluginEnvironmentValidateConfigParams,
PluginEnvironmentValidationResult,
} from "@paperclipai/plugin-sdk";
@@ -38,7 +39,11 @@ import {
} from "./sandbox-cr-orchestrator.js";
import { execInPod, execInPodStreaming, wrapCommandWithEnv } from "./pod-exec.js";
import { performSyncIn, performSyncOut, type PodStreamExec } from "./file-sync.js";
-import { checkLeaseResumable, destroyLeaseResources } from "./lease-lifecycle.js";
+import {
+ checkLeaseResumable,
+ destroyLeaseResources,
+ waitForWorkloadGone,
+} from "./lease-lifecycle.js";
import {
appendNetworkEgressDenyHint,
createScopedNetworkEgressPolicyOrReleaseWorkload,
@@ -578,7 +583,7 @@ const plugin = definePlugin({
async onEnvironmentReleaseLease(
params: PluginEnvironmentReleaseLeaseParams,
- ): Promise<void> {
+ ): Promise<PluginEnvironmentTerminationReceipt | void> {
if (!params.providerLeaseId) return;
const config = kubernetesProviderConfigSchema.parse(params.config);
const namespace =
@@ -613,11 +618,22 @@ const plugin = definePlugin({
?? (err as { code?: number; statusCode?: number }).statusCode;
if (code !== 404) throw err;
}
+
+ // The server grants continuation after a stopped run only with a
+ // termination receipt; without one a cancelled run's queued comment
+ // waits on `remote_cleanup` forever (REN-841). Claim `destroyed` only
+ // once the workload is confirmed gone.
+ const gone = await waitForWorkloadGone(clients, {
+ namespace,
+ name: params.providerLeaseId,
+ backend: leaseBackend,
+ });
+ if (gone) return { providerLeaseId: params.providerLeaseId, state: "destroyed" };
},
async onEnvironmentDestroyLease(
params: PluginEnvironmentDestroyLeaseParams,
- ): Promise<void> {
+ ): Promise<PluginEnvironmentTerminationReceipt | void> {
if (!params.providerLeaseId) return;
const config = kubernetesProviderConfigSchema.parse(params.config);
const namespace =
@@ -658,6 +674,13 @@ const plugin = definePlugin({
podName,
secretName,
});
+ const gone = await waitForWorkloadGone(clients, {
+ namespace,
+ name: params.providerLeaseId,
+ backend: leaseBackend,
+ podName,
+ });
+ if (gone) return { providerLeaseId: params.providerLeaseId, state: "destroyed" };
},
async onEnvironmentExecute(
diff --git a/packages/plugins/sandbox-providers/kubernetes/test/unit/lease-lifecycle.test.ts b/packages/plugins/sandbox-providers/kubernetes/test/unit/lease-lifecycle.test.ts
index af0875f..d775799 100644
--- a/packages/plugins/sandbox-providers/kubernetes/test/unit/lease-lifecycle.test.ts
+++ b/packages/plugins/sandbox-providers/kubernetes/test/unit/lease-lifecycle.test.ts
@@ -3,6 +3,7 @@ import {
checkLeaseResumable,
destroyLeaseResources,
isKubeNotFoundError,
+ waitForWorkloadGone,
} from "../../src/lease-lifecycle.js";
const SANDBOX_GROUP = "agents.x-k8s.io";
@@ -346,3 +347,64 @@ describe("destroyLeaseResources", () => {
).rejects.toThrow("forbidden");
});
});
+
+describe("waitForWorkloadGone", () => {
+ const input = { namespace: "ns", name: "pc-abc", backend: "sandbox-cr" as const, pollMs: 1 };
+
+ it("is true once the Sandbox CR and the pod return 404", async () => {
+ const getCr = vi.fn()
+ .mockResolvedValueOnce(readySandboxCr("pc-abc-pod"))
+ .mockRejectedValue(notFound());
+ const readPod = vi.fn().mockRejectedValue(notFound());
+ const clients = { custom: { getNamespacedCustomObject: getCr }, core: { readNamespacedPod: readPod } };
+
+ await expect(
+ waitForWorkloadGone(clients as never, { ...input, podName: "pc-abc-pod" }),
+ ).resolves.toBe(true);
+ expect(getCr).toHaveBeenCalledTimes(2);
+ expect(getCr).toHaveBeenCalledWith(expect.objectContaining({
+ group: SANDBOX_GROUP, version: SANDBOX_VERSION, plural: SANDBOX_PLURAL, namespace: "ns", name: "pc-abc",
+ }));
+ });
+
+ it("is false while the workload still exists at the deadline", async () => {
+ const clients = {
+ custom: { getNamespacedCustomObject: vi.fn().mockResolvedValue(readySandboxCr()) },
+ };
+
+ await expect(
+ waitForWorkloadGone(clients as never, { ...input, timeoutMs: 5 }),
+ ).resolves.toBe(false);
+ });
+
+ it("is false while the pod still exists even if the workload is gone", async () => {
+ const clients = {
+ custom: { getNamespacedCustomObject: vi.fn().mockRejectedValue(notFound()) },
+ core: { readNamespacedPod: vi.fn().mockResolvedValue({ status: { phase: "Running" } }) },
+ };
+
+ await expect(
+ waitForWorkloadGone(clients as never, { ...input, podName: "pc-abc-pod", timeoutMs: 5 }),
+ ).resolves.toBe(false);
+ });
+
+ it("checks the Job for job-backend leases", async () => {
+ const readJob = vi.fn().mockRejectedValue(notFound());
+ const clients = { batch: { readNamespacedJobStatus: readJob } };
+
+ await expect(
+ waitForWorkloadGone(clients as never, { ...input, backend: "job" }),
+ ).resolves.toBe(true);
+ expect(readJob).toHaveBeenCalledWith({ namespace: "ns", name: "pc-abc" });
+ });
+
+ it("is false (never throws) when a read fails with another error", async () => {
+ const clients = {
+ custom: {
+ getNamespacedCustomObject: vi.fn().mockRejectedValue(Object.assign(new Error("x"), { code: 403 })),
+ },
+ };
+
+ await expect(waitForWorkloadGone(clients as never, input)).resolves.toBe(false);
+ });
+});
diff --git a/packages/plugins/sandbox-providers/kubernetes/test/unit/plugin-lease-lifecycle.test.ts b/packages/plugins/sandbox-providers/kubernetes/test/unit/plugin-lease-lifecycle.test.ts
index 4c23410..f4fd073 100644
--- a/packages/plugins/sandbox-providers/kubernetes/test/unit/plugin-lease-lifecycle.test.ts
+++ b/packages/plugins/sandbox-providers/kubernetes/test/unit/plugin-lease-lifecycle.test.ts
@@ -184,12 +184,19 @@ describe("onEnvironmentDestroyLease", () => {
const deletePod = vi.fn().mockResolvedValue({});
const deleteSecret = vi.fn().mockResolvedValue({});
h.clients = {
- custom: { deleteNamespacedCustomObject: deleteCr },
- core: { deleteNamespacedPod: deletePod, deleteNamespacedSecret: deleteSecret },
+ custom: {
+ deleteNamespacedCustomObject: deleteCr,
+ getNamespacedCustomObject: vi.fn().mockRejectedValue(notFound()),
+ },
+ core: {
+ deleteNamespacedPod: deletePod,
+ deleteNamespacedSecret: deleteSecret,
+ readNamespacedPod: vi.fn().mockRejectedValue(notFound()),
+ },
batch: { deleteNamespacedJob: vi.fn() },
};
- await plugin.definition.onEnvironmentDestroyLease!({
+ const receipt = await plugin.definition.onEnvironmentDestroyLease!({
driverKey: "kubernetes",
companyId: "acme",
environmentId: "env-1",
@@ -209,14 +216,47 @@ describe("onEnvironmentDestroyLease", () => {
namespace: "paperclip-acme",
name: "pc-abc-env",
});
+ expect(receipt).toEqual({ providerLeaseId: "pc-abc", state: "destroyed" });
});
it("is idempotent: resolves cleanly when every resource is already gone (404)", async () => {
h.clients = {
- custom: { deleteNamespacedCustomObject: vi.fn().mockRejectedValue(notFound()) },
+ custom: {
+ deleteNamespacedCustomObject: vi.fn().mockRejectedValue(notFound()),
+ getNamespacedCustomObject: vi.fn().mockRejectedValue(notFound()),
+ },
core: {
deleteNamespacedPod: vi.fn().mockRejectedValue(notFound()),
deleteNamespacedSecret: vi.fn().mockRejectedValue(notFound()),
+ readNamespacedPod: vi.fn().mockRejectedValue(notFound()),
+ },
+ batch: { deleteNamespacedJob: vi.fn() },
+ };
+
+ await expect(
+ plugin.definition.onEnvironmentDestroyLease!({
+ driverKey: "kubernetes",
+ companyId: "acme",
+ environmentId: "env-1",
+ config: CONFIG,
+ providerLeaseId: "pc-abc",
+ leaseMetadata: leaseMetadata(),
+ }),
+ ).resolves.toEqual({ providerLeaseId: "pc-abc", state: "destroyed" });
+ });
+
+ it("returns no receipt when the gone check cannot read the cluster", async () => {
+ h.clients = {
+ custom: {
+ deleteNamespacedCustomObject: vi.fn().mockResolvedValue({}),
+ getNamespacedCustomObject: vi.fn().mockRejectedValue(
+ Object.assign(new Error("forbidden"), { code: 403 }),
+ ),
+ },
+ core: {
+ deleteNamespacedPod: vi.fn().mockResolvedValue({}),
+ deleteNamespacedSecret: vi.fn().mockResolvedValue({}),
+ readNamespacedPod: vi.fn().mockRejectedValue(notFound()),
},
batch: { deleteNamespacedJob: vi.fn() },
};
@@ -261,8 +301,12 @@ describe("onEnvironmentDestroyLease", () => {
core: {
deleteNamespacedPod: vi.fn().mockResolvedValue({}),
deleteNamespacedSecret: vi.fn().mockResolvedValue({}),
+ readNamespacedPod: vi.fn().mockRejectedValue(notFound()),
+ },
+ batch: {
+ deleteNamespacedJob: deleteJob,
+ readNamespacedJobStatus: vi.fn().mockRejectedValue(notFound()),
},
- batch: { deleteNamespacedJob: deleteJob },
};
await plugin.definition.onEnvironmentDestroyLease!({
@@ -280,3 +324,71 @@ describe("onEnvironmentDestroyLease", () => {
expect(deleteCr).not.toHaveBeenCalled();
});
});
+
+describe("onEnvironmentReleaseLease", () => {
+ it("returns a destroyed receipt once the Sandbox CR is gone (REN-841)", async () => {
+ const deleteCr = vi.fn().mockResolvedValue({});
+ h.clients = {
+ custom: {
+ deleteNamespacedCustomObject: deleteCr,
+ getNamespacedCustomObject: vi.fn().mockRejectedValue(notFound()),
+ },
+ };
+
+ const receipt = await plugin.definition.onEnvironmentReleaseLease!({
+ driverKey: "kubernetes",
+ companyId: "acme",
+ environmentId: "env-1",
+ config: CONFIG,
+ providerLeaseId: "pc-abc",
+ leaseMetadata: leaseMetadata(),
+ });
+
+ expect(deleteCr).toHaveBeenCalledWith(
+ expect.objectContaining({ namespace: "paperclip-acme", name: "pc-abc" }),
+ );
+ expect(receipt).toEqual({ providerLeaseId: "pc-abc", state: "destroyed" });
+ });
+
+ it("returns a destroyed receipt when the Sandbox CR was already deleted", async () => {
+ h.clients = {
+ custom: {
+ deleteNamespacedCustomObject: vi.fn().mockRejectedValue(notFound()),
+ getNamespacedCustomObject: vi.fn().mockRejectedValue(notFound()),
+ },
+ };
+
+ await expect(
+ plugin.definition.onEnvironmentReleaseLease!({
+ driverKey: "kubernetes",
+ companyId: "acme",
+ environmentId: "env-1",
+ config: CONFIG,
+ providerLeaseId: "pc-abc",
+ leaseMetadata: leaseMetadata(),
+ }),
+ ).resolves.toEqual({ providerLeaseId: "pc-abc", state: "destroyed" });
+ });
+
+ it("returns no receipt when the gone check fails", async () => {
+ h.clients = {
+ custom: {
+ deleteNamespacedCustomObject: vi.fn().mockResolvedValue({}),
+ getNamespacedCustomObject: vi.fn().mockRejectedValue(
+ Object.assign(new Error("server error"), { code: 500 }),
+ ),
+ },
+ };
+
+ await expect(
+ plugin.definition.onEnvironmentReleaseLease!({
+ driverKey: "kubernetes",
+ companyId: "acme",
+ environmentId: "env-1",
+ config: CONFIG,
+ providerLeaseId: "pc-abc",
+ leaseMetadata: leaseMetadata(),
+ }),
+ ).resolves.toBeUndefined();
+ });
+});
+7
View File
@@ -0,0 +1,7 @@
# Upstream paperclipai/paperclip commit this image is built from (REN-401).
# a027f76 is the master commit the nightly image ran when this was pinned, so
# the only change against that image is the patch next to this file.
# PAPERCLIP_VERSION is `git describe --tags --match 'v*' --long` of that
# commit, the value upstream stamps into its own images. Bump both together.
PAPERCLIP_COMMIT=a027f76a726e8a556674eded807c2de0e55f5cc0
PAPERCLIP_VERSION=v2026.916.0-219-ga027f76a7
+1 -1
View File
@@ -1,4 +1,4 @@
FROM alpine:3.21@sha256:48b0309ca019d89d40f670aa1bc06e426dc0931948452e8491e3d65087abc07d
FROM alpine:3.24@sha256:294b683cb724975bec92580e1e685676bd4b50bda910ddb8c51d4cabeaec77e6
ARG TOFU_VERSION=1.11.0
+1 -1
View File
@@ -1,4 +1,4 @@
FROM alpine:3.21@sha256:48b0309ca019d89d40f670aa1bc06e426dc0931948452e8491e3d65087abc07d
FROM alpine:3.24@sha256:294b683cb724975bec92580e1e685676bd4b50bda910ddb8c51d4cabeaec77e6
# Everything `bootstrap.sh vmtest` needs, so the rebuild test can run as a Job in
# the cluster instead of on a workstation. The workstation has 31G and the test
@@ -16,7 +16,7 @@ credentials are out of scope (see "Deferred").
|---|---|
| Execution model | **B — server-local runs** (upstream default): agent CLIs are child processes of the server, in the server container. Trial only. |
| Upgrade path | If Paperclip is kept: **C** — `@paperclipai/plugin-kubernetes` sandbox provider + kubernetes-sigs agent-sandbox controller (`agents.x-k8s.io`), per-run Pods and Secrets. Separate spec. |
| Claude auth | **One shared Claude subscription AI connection**, created once via Paperclip's local sign-in (`claude auth login` into `ai-local-logins/<id>`); Paperclip stores and refreshes it. Server-env `CLAUDE_CODE_OAUTH_TOKEN` is not used: `stripAiAuthBindings` blanks it for managed runs, and upstream accepts no pasted setup-token (the device-code flow needs a Daytona sandbox). |
| Claude auth | **One shared Claude subscription AI connection**, created once via Paperclip's local sign-in (`claude auth login` into `ai-local-logins/<id>`), then its value replaced with a long-lived `claude setup-token` token. Paperclip stores the value as company secret "My Claude subscription" and injects it per run as `CLAUDE_CODE_OAUTH_TOKEN`; it never refreshes Anthropic credentials, so the login's ~8h access token expires (runs then fail with "ACP agent reported a terminal access failure", 0 tokens). Renew by rotating that secret with a new setup-token (~yearly). Server-env `CLAUDE_CODE_OAUTH_TOKEN` is not used: `stripAiAuthBindings` blanks it for managed runs, and upstream accepts no pasted setup-token (the device-code flow needs a Daytona sandbox). |
| Bot credentials | Out of scope. Future "AIR-Manager" Paperclip role handles permission requests. |
| Exposure | LAN-only, behind an Authentik forward-auth gate, then Paperclip's own login. |
@@ -64,7 +64,32 @@ All modeled on `kubernetes/apps/paperless/` unless stated.
- Starts as root: upstream `docker-entrypoint.sh` remaps the `node` user, chowns
`/paperclip`, then drops to uid 1000 via `gosu`. Caps limited to CHOWN,
DAC_OVERRIDE, FOWNER, SETGID, SETUID; `fsGroup: 1000`.
- `automountServiceAccountToken: false` (all agents share the pod filesystem).
- `serviceAccountName: paperclip-prometheus-read` with
`automountServiceAccountToken: true`. All agents share the pod filesystem, so all
of them can read that token — it is mounted anyway because the Role behind it
grants exactly `get` on `services/proxy` for
`kube-prometheus-stack-prometheus:9090` and
`kube-prometheus-stack-alertmanager:9093` in `monitoring`, and nothing else
(`kubernetes/apps/paperclip/prometheus-read-rbac.yaml`, REN-36 then REN-95).
It was `false` until then.
Three things about that grant are worth knowing before you use or debug it:
- **It scopes the HTTP method, not the endpoint.** The apiserver maps GET→`get`,
POST→`create`, PUT→`update` on a service-proxy request, so `get` alone refuses
`POST /-/reload` and `POST /-/quit` in the authorizer. It does *not* narrow
which GET endpoints are reachable: the whole read surface of both services is,
including `/api/v1/status/config` (scrape credentials there render as
`<secret>`) and the web UI.
- **Force GET in the caller.** Prometheus accepts both GET and POST on
`/api/v1/query`; under this Role only the GET form works, so a client library
that switches to POST for long queries will 403 for a reason that has nothing
to do with the query.
- **If reads start 403ing, check the Service name against `resourceNames`
first.** `resourceNames` is matched verbatim, and
`kubernetes/apps/monitoring/helmrelease-prometheus.yaml` floats the chart at
`>=72.0.0` — a release rename breaks this path silently,
with everything still looking correct in git. The port-qualified form is the
only one granted: `svc`, `svc:9090` and `http:svc:9090` are three different
strings to the authorizer.
- Port 3100; `Service paperclip` ClusterIP :3100.
- Probes: startup and readiness on `GET /api/health` with `Host: localhost` (the
private-hostname guard rejects the pod IP); liveness is a TCP check, since
@@ -164,7 +189,8 @@ available since v0.35.0). First use of digest reflection in this repo.
**as the node user** (the entrypoint makes exec sessions root, and root-owned 0600
credentials are unreadable to the server):
`kubectl exec -it -n paperclip deploy/paperclip -- gosu node sh -c 'export CLAUDE_CONFIG_DIR=<shown path> && mkdir -p "$CLAUDE_CONFIG_DIR" && claude auth login'`
Repeat after loss of the PVC or database.
Then Settings → Secrets → "My Claude subscription": replace the value with the
output of `claude setup-token`. Repeat both after loss of the database.
## Verification
- Flux Kustomization `paperclip` Ready; CNPG `pclp-pg` healthy; first ScheduledBackup
+15
View File
@@ -165,6 +165,21 @@ permanent recovery.
---
## Velero restore-test: 80% OSD capacity gate
The monthly Velero restore-test restores into the production Ceph pools. Before
each schedule's restore it projects the restore's raw size (DataUpload
`totalBytes` x the pool's replication/EC factor, spread over all OSDs) onto
current OSD usage from Prometheus. If the fullest OSD would go above **80%**
(`OSD_MAX_PCT` in `restore-test-cronjob.yaml`), that schedule is not restored:
the Job log shows it as **SKIP** with the projected %, and the summary lists it
under "Skipped (backup NOT restore-tested)". A SKIP does not fail the Job, so
read the summary each month. If the projection cannot be made (Prometheus
down, unsized DataUpload), the schedule is not restored and counts as FAIL.
Background: REN-441, REN-442.
---
## CNPG restore-test (verify backups are restorable — non-destructive)
The monthly Velero restore-test (`kubernetes/infrastructure/velero/`) exercises
@@ -0,0 +1,71 @@
# Runbook — roll back a Home Assistant image bump
Use when an automatic Home Assistant update (a
`chore(image-automation): bump ghcr.io/home-assistant/home-assistant:<new>`
commit on `master`) breaks Home Assistant. The owner approves the rollback
and its timing. Atlas writes the PR; Argus merges it.
## Why a plain `git revert` is not enough
Image automation (`kubernetes/infrastructure/image-automation/`) re-scans
the registry every hour and rewrites the tag every 30 minutes to the
highest release matching the `home-assistant` ImagePolicy. A plain revert
of the bump commit would be bumped forward again within about an hour.
So the rollback commit does two things at once: it reverts the tag **and**
drops the `# {"$imagepolicy": ...}` marker from that image line. Without
the marker the Setters strategy has nothing to rewrite, so the old tag
stays pinned. It is still one commit, and reverting that commit restores
automation.
## Before you roll back
1. Find the bump commit:
```sh
git log --oneline -5 origin/master -- kubernetes/apps/home-assistant/deployment.yaml
```
2. Check the release notes of the broken version for a **database schema**
change. Home Assistant migrates the recorder schema (CNPG cluster
`ha-pg`) on start and cannot downgrade it. An older version started on a
newer schema runs without recorder history until the schema matches
again. If the bump crossed a schema change, tell the owner before going
on: the choice is roll back without history, or restore the recorder
database from backup as a separate step.
## Roll back (one commit, one PR)
```sh
git worktree add -b atlas/ha-rollback-<old> "$WT" origin/master && cd "$WT"
git revert --no-commit <bump-sha>
# In kubernetes/apps/home-assistant/deployment.yaml, delete the trailing
# # {"$imagepolicy": "flux-system:home-assistant"}
# from the home-assistant image line. Leave every other line alone.
git diff --cached --stat # expect: 1 file, 1 line changed
git commit -m "fix(home-assistant): pin <old>, pause image automation (bump to <new> broke HA)"
git push -u origin HEAD
```
The PR description states: broken version, pinned version, symptom, schema
check result, and "revert this commit to resume automatic updates".
HA-impact review and merge follow [README.md](../README.md#2-ha-impact-review-before-merge).
On merge Flux applies the Deployment (strategy `Recreate`): Home Assistant
restarts once, about one to two minutes of downtime.
## Verify
```sh
kubectl -n home-assistant get deploy home-assistant \
-o jsonpath='{.spec.template.spec.containers[?(@.name=="home-assistant")].image}'
kubectl -n home-assistant rollout status deploy/home-assistant
```
Read-only commands only (see REN-240 protection rule 1). One hour after
merge, confirm no new `chore(image-automation)` commit touched
`deployment.yaml`.
## Resume automatic updates
When a fixed Home Assistant release is out, revert the rollback commit. The
marker comes back, and image automation bumps to the newest release on its
next pass. That bump is itself a Home Assistant restart.
@@ -48,7 +48,7 @@ spec:
# cert when doing server-side OIDC token exchange. Bundle both
# roots into one PEM since NODE_EXTRA_CA_CERTS accepts one file.
- name: fetch-le-staging-roots
image: curlimages/curl:8.10.1
image: curlimages/curl:8.22.0@sha256:58adaa4e8dca9c988bae2aba4ab3434a0bb2da16bbe3f92dec39ec7785166777
command:
- sh
- -c
@@ -70,7 +70,7 @@ spec:
mountPath: /ca
containers:
- name: audiobookshelf
image: ghcr.io/advplyr/audiobookshelf:2.36.1 # {"$imagepolicy": "flux-system:audiobookshelf"}
image: ghcr.io/advplyr/audiobookshelf:2.37.1 # {"$imagepolicy": "flux-system:audiobookshelf"}
ports:
- name: http
containerPort: 80
@@ -2121,6 +2121,74 @@ data:
- url: https://dash.renner.uno/login/generic_oauth
matching_mode: strict
# Matrix (REN-567): upstream login for MAS (account.matrix.renner.uno).
# Git owns this provider, its application and the member list.
# Public client + PKCE, so there is no client secret to share.
# RS256 with the built-in self-signed keypair: a public client has no
# secret for HS256, and MAS verifies the ID token signature.
- id: matrix-users-group
model: authentik_core.group
identifiers:
name: Matrix Users
state: present
attrs:
is_superuser: false
# Every member can sign in to Matrix and gets an account named
# after their Authentik username. Add/remove members HERE.
users:
- !Find [authentik_core.user, [username, k.renner]]
- id: matrix-mas-provider
model: authentik_providers_oauth2.oauth2provider
identifiers:
name: Matrix (MAS)
state: present
attrs:
authentication_flow: !KeyOf passkey-passwordless-flow
authorization_flow: !KeyOf passkey-stepup-flow
invalidation_flow: !Find [authentik_flows.flow, [slug, default-provider-invalidation-flow]]
client_type: public
client_id: matrix-mas
# Authentik 2026.5 checks the grant type against this list, and a
# provider created by a blueprint starts with it empty, so every
# authorize fails with invalid_request ("Invalid grant_type for
# provider"). Providers made in the UI get the defaults.
grant_types:
- authorization_code
- refresh_token
signing_key: !Find [authentik_crypto.certificatekeypair, [name, authentik Self-signed Certificate]]
property_mappings:
- !Find [authentik_providers_oauth2.scopemapping, [managed, goauthentik.io/providers/oauth2/scope-openid]]
- !Find [authentik_providers_oauth2.scopemapping, [managed, goauthentik.io/providers/oauth2/scope-profile]]
- !Find [authentik_providers_oauth2.scopemapping, [managed, goauthentik.io/providers/oauth2/scope-email]]
redirect_uris:
# The path ends in the provider ULID from apps/matrix/mas.yaml.
- url: https://account.matrix.renner.uno/upstream/callback/01M4480KWZGN9HBNB5SSNGT2M1
matching_mode: strict
- model: authentik_core.application
identifiers:
slug: matrix
state: present
attrs:
name: Matrix
slug: matrix
provider: !KeyOf matrix-mas-provider
meta_launch_url: https://element.renner.uno
meta_description: "Matrix chat (Element)"
# Only the Matrix Users group passes.
- model: authentik_policies.policybinding
identifiers:
target: !Find [authentik_core.application, [slug, matrix]]
group: !KeyOf matrix-users-group
order: 0
state: present
attrs:
enabled: true
negate: false
failure_result: false
# Superseded by the single passkey-webauthn-validation stage above.
# Their flowstagebindings are FK-CASCADEd away with them; the
# identification stage's webauthn_stage FK is SET_NULL and is
+29 -1
View File
@@ -5,6 +5,11 @@ metadata:
namespace: evcc
labels:
app.kubernetes.io/name: evcc
annotations:
# The MQTT client certificate reaches evcc as env (below), which does not
# follow a renewal. cert-manager renews it every ~60 days; Reloader then
# restarts evcc so it picks up the new PEMs before the old ones expire.
secret.reloader.stakater.com/reload: mqtt-evcc-client-tls
spec:
replicas: 1
# RWO PVC (`evcc-data`, ceph-block) can't be mounted twice, so the
@@ -23,13 +28,36 @@ spec:
enableServiceLinks: false
containers:
- name: evcc
image: evcc/evcc:0.310.1
image: evcc/evcc:0.316.2@sha256:070c8a8912c5107e8424cef60bf8c3d3cac0eb32aa28d1b021d226545f0aac7b
# evcc auto-discovers /etc/evcc.yaml on its default search path;
# the file is delivered (with the MQTT password) via the
# sops-encrypted evcc-config Secret mounted below.
env:
- name: TZ
value: Europe/Berlin
# MQTT by client certificate (register account evcc-client,
# REN-953) on the mTLS listener. These override the mqtt block of
# evcc.yaml (viper AutomaticEnv, checked against 0.316.2); the
# file's user/password are ignored there, as the broker takes the
# username from the certificate CN. evcc wants the PEM text, not
# a path.
- name: EVCC_MQTT_BROKER
value: tls://mosquitto.home-assistant.svc.cluster.local:8884
- name: EVCC_MQTT_CACERT
valueFrom:
secretKeyRef:
name: mqtt-evcc-client-tls
key: ca.crt
- name: EVCC_MQTT_CLIENTCERT
valueFrom:
secretKeyRef:
name: mqtt-evcc-client-tls
key: tls.crt
- name: EVCC_MQTT_CLIENTKEY
valueFrom:
secretKeyRef:
name: mqtt-evcc-client-tls
key: tls.key
ports:
- name: http
containerPort: 7070
+75
View File
@@ -30,7 +30,42 @@ metadata:
# Web Service 9 = Music Assistant
# Web Service 10 = TRMNL
# Web Service 11 = Paperless (gate-level only, see its entry)
# Web Service 12 = Element Web
# Web Service 13 = Matrix (Synapse client API)
# Web Service 14 = Matrix Authentication Service
#
# CORRECTION (REN-21, 2026-09-25) to the Web Service 11 comment further down,
# which claims that an in-cluster probe of the paperless ClusterIP "needs a
# CiliumNetworkPolicy first — the monitoring probes get away without one only
# because their targets share a namespace with the prober".
#
# That is wrong, and it was wrong when written. It is stated here rather than
# fixed in place because the sentence lives inside the `config.yaml: |` block
# scalar below: any edit to it changes ConfigMap DATA, and
# `configmap.reloader.stakater.com/reload: gatus-config`
# (deployment.yaml#reloader) would then roll the gatus Deployment — a
# production restart for a comment. This header is outside `data:`, so it is
# inert; the served config is byte-identical.
#
# * When written, the paperless baseline admitted the whole monitoring
# namespace on every port, and monitoring is where blackbox-exporter runs.
# That admit is gone (REN-28); the probe is now admitted by the dedicated
# ../../infrastructure/network-policies/paperless-ns.yaml#paperless-allow-blackbox,
# scoped to blackbox-exporter on the paperless pod's :8000. Cilium unions
# the allow rules of every CNP selecting an endpoint, so nothing else is
# required.
# * The in-cluster paperless probe therefore exists:
# ../monitoring-rules/probes-blackbox.yaml#paperless-app-health, target
# http://paperless.paperless.svc.cluster.local:80/accounts/login/
# * The claim does NOT generalise to gatus itself. Gatus runs in `apps`,
# which is a different source namespace; a gatus-sourced in-cluster check
# would need its own allow, exactly as
# cnp-cross-namespace-allow-apps-gatus-to-monitored-services describes.
#
# The Web Service 11 entry below stays a reachability-only check on purpose.
# The app-health half of the pair is the blackbox probe named above.
data:
# anchor: gatus-endpoints
config.yaml: |
storage:
type: sqlite
@@ -196,6 +231,46 @@ data:
conditions:
- "[STATUS] == any(200, 301, 302)"
# Matrix (REN-663): Element Web, the Synapse client API and MAS.
- name: Web Service 12
group: services
url: https://element.renner.uno/config.json
interval: 60s
ui:
hide-hostname: true
hide-url: true
hide-port: true
hide-conditions: true
hide-errors: true
conditions:
- "[STATUS] == 200"
- name: Web Service 13
group: services
url: https://matrix.renner.uno/_matrix/client/versions
interval: 60s
ui:
hide-hostname: true
hide-url: true
hide-port: true
hide-conditions: true
hide-errors: true
conditions:
- "[STATUS] == 200"
- name: Web Service 14
group: services
url: https://account.matrix.renner.uno/.well-known/openid-configuration
interval: 60s
ui:
hide-hostname: true
hide-url: true
hide-port: true
hide-conditions: true
hide-errors: true
conditions:
- "[STATUS] == 200"
# Removed 2026-05-21: Jellyfin (media.renner.uno), Wiki (wiki.renner.uno),
# InfluxDB (influx.renner.uno) — hostnames NXDOMAIN, no Ingress; services
# no longer deployed. Re-add when/if they come back.
+1
View File
@@ -6,6 +6,7 @@ metadata:
labels:
app: gatus
annotations:
# anchor: reloader
# Gatus reads its config once at startup and never re-reads the file, so
# without this a ConfigMap change reconciles cleanly and then does nothing:
# git and the running checks drift apart silently, with no failed resource
+2
View File
@@ -6,6 +6,8 @@ kind: Kustomization
# and verified. See MIGRATION-gitea-woodpecker.md.
resources:
- statefulset.yaml
# The live size of the data volume; see the file (REN-583).
- pvc.yaml
- service.yaml
- ingressroute-ssh.yaml
- ingress.yaml
+39
View File
@@ -0,0 +1,39 @@
# The live data volume of gitea-0, owned here so its size is set in git
# (REN-583). The StatefulSet controller created this claim from the
# volumeClaimTemplates in statefulset.yaml, but that template is immutable on
# an existing StatefulSet, so changing the size there cannot be applied. A
# PVC's resources.requests.storage CAN grow in place (ceph-block has
# allowVolumeExpansion: true; ceph-csi grows the RBD image and the filesystem
# online, no pod restart). Flux applies this over the existing claim with
# server-side apply and the resize follows.
#
# - Name, namespace, accessModes, storageClassName and volumeMode must match
# the live claim exactly: they are immutable, a mismatch fails the whole
# gitea Kustomization (no change to the live claim).
# - volumeName must stay: kustomize-controller has owned spec.volumeName
# since the namespace move pre-created this claim (eb23d3ac, #878).
# Without it, server-side apply tries to clear the field and the API server
# rejects the whole claim as an immutable-spec change.
# - Grow only. A smaller value is rejected by the API server.
# - prune: disabled, so removing this file from git never deletes the claim
# and its data. To hand ownership back, delete the file; the claim stays.
#
# Size history: 20Gi -> 40Gi 2026-07-22 (#336, live resize by hand);
# 40Gi -> 60Gi 2026-10-03 (REN-583, after the volume filled again on REN-580).
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: data-gitea-0
namespace: gitea
labels:
app.kubernetes.io/name: gitea
annotations:
kustomize.toolkit.fluxcd.io/prune: disabled
spec:
accessModes: ["ReadWriteOnce"]
storageClassName: ceph-block
volumeMode: Filesystem
volumeName: pvc-e7c56db2-481d-40cb-b94a-b264b7b4b5be
resources:
requests:
storage: 60Gi
+6 -10
View File
@@ -37,7 +37,7 @@ spec:
# both handled as explicit steps in MIGRATION-gitea-woodpecker.md. Pinned
# to match the LXC for a clean SQLite lift; no imagepolicy marker (an
# auto-bump across versions on live SQLite data must never be applied).
image: gitea/gitea:1.21.4-rootless
image: gitea/gitea:1.21.4-rootless@sha256:600f1f1e1d090c763866db16882b5eac5c6a80b7664ee53bec0806c656c0033f
env:
- name: GITEA_WORK_DIR
value: /var/lib/gitea
@@ -147,14 +147,10 @@ spec:
accessModes: ["ReadWriteOnce"]
storageClassName: ceph-block
resources:
# Expanded 20Gi -> 40Gi on 2026-07-22 (ceph-block online resize) to
# clear a 100%-full outage (#336). The live PVC was resized directly.
# NOTE: volumeClaimTemplates is immutable on an existing StatefulSet,
# so bumping this value cannot be `kubectl apply`-ed in place — Flux
# will reject the whole object. Landing this size change requires a
# one-time `kubectl delete statefulset gitea -n gitea --cascade=orphan`
# (pod + PVC keep running) so Flux re-creates the STS from this
# template and re-adopts them. After the cleanup_packages GC reclaims
# the ~10G of orphaned blobs, real usage is ~9G, so 40Gi is headroom.
# This template only applies when the claim does not exist yet. The
# live size of data-gitea-0 is set in pvc.yaml (REN-583), not here:
# volumeClaimTemplates is immutable on an existing StatefulSet, so a
# change to this value cannot be applied and Flux would reject the
# whole object. Leave it at 40Gi.
requests:
storage: 40Gi
@@ -1,15 +0,0 @@
apiVersion: external-secrets.io/v1
kind: ExternalSecret
metadata:
name: home-assistant-backup-password
namespace: home-assistant
spec:
refreshInterval: 1h
secretStoreRef:
kind: ClusterSecretStore
name: openbao
target:
name: home-assistant-backup-password # keeps the old Secret's name — consumers unchanged
dataFrom:
- extract:
key: apps/home-assistant/backup-password
@@ -60,7 +60,7 @@ spec:
# repo's configuration.yaml reads this key, so HA does not start
# without it. Removing this init container takes the recorder down.
- name: render-db-url
image: busybox:1.36
image: busybox:1.38@sha256:fd7dc98638c8e305f4dc34e979f1c0fdfdcaeb0fbf8fcff77ae834b6da3d7e6e
command:
- sh
- -c
@@ -95,7 +95,7 @@ spec:
memory: 32Mi
containers:
- name: home-assistant
image: ghcr.io/home-assistant/home-assistant:2026.9.3 # {"$imagepolicy": "flux-system:home-assistant"}
image: ghcr.io/home-assistant/home-assistant:2026.9.4 # {"$imagepolicy": "flux-system:home-assistant"}
env:
- name: TZ
value: Europe/Berlin
@@ -159,7 +159,7 @@ spec:
# substitution to POD_IP so nginx-runtime variables like $host
# / $http_x_forwarded_for in the template stay intact.
- name: proxy
image: nginxinc/nginx-unprivileged:1.27-alpine
image: nginxinc/nginx-unprivileged:1.31-alpine@sha256:26b0bf6fbf07297983cb341998d79c831508787de26627dd2a112321b9c3a4af
env:
- name: POD_IP
valueFrom:
@@ -193,7 +193,7 @@ spec:
# any LAN client can edit, matching the user's trust-the-network
# model. Runs as root so its writes match HA's root-owned files.
- name: code-server
image: codercom/code-server:4.118.0
image: codercom/code-server:4.140.0@sha256:1c9ad972a78450f430155144110da4c02d3627c72a598e9197e2781fb9f92e28
args:
- "--auth=none"
- "--bind-addr=0.0.0.0:8080"
@@ -253,7 +253,7 @@ spec:
# in the PVC's remote URL; reload auth uses a dedicated long-lived token.
# Runs as root to match HA's root-owned /config files. See config-sync.sh.
- name: config-sync
image: alpine/git:2.54.0
image: alpine/git:2.54.0@sha256:a4bb51f1a3553df194ce679fc1db721d8bfba2046fa1a88fe9d4ac551ffbce25
command: ["/bin/sh", "/scripts/sync.sh"]
env:
- name: SYNC_BRANCH
@@ -36,7 +36,7 @@ spec:
type: RuntimeDefault
containers:
- name: esphome
image: ghcr.io/esphome/esphome:2026.6.2
image: ghcr.io/esphome/esphome:2026.9.1@sha256:776a845d508909bf426d2ee7bdd81796361ebe6a7f091807ce1d6d0b48985413
imagePullPolicy: IfNotPresent
# Default entrypoint runs the dashboard (Device Builder) against the
# mounted /config — no command override needed.
@@ -31,17 +31,70 @@ metadata:
namespace: home-assistant
spec:
instances: 2
# switchover, not CNPG's default `restart`: any change that rolls the pods
# (walStorage below did) then promotes the already-rolled replica instead of
# restarting the primary in place, so the recorder loses seconds of writes
# rather than stopDelay plus a pg_wal move plus startup (REN-176).
primaryUpdateMethod: switchover
smartShutdownTimeout: 10
stopDelay: 60
imageName: ghcr.io/cloudnative-pg/postgresql:16
storage:
storageClass: ceph-block
# Sized for the migrated statistics plus 7 days of states at the current
# rate: statistics 10.8M rows + statistics_short_term 1.9M (~1.8 GB with
# indexes in Postgres) and ~18M states rows for the purge_keep_days:7 window
# (~4 GB). 20Gi leaves room for autovacuum bloat and index churn.
# ceph-block has allowVolumeExpansion: true, so this can grow in place.
size: 20Gi
# Sized for WAL headroom during an archiving stall, not for table growth.
# The data itself needs far less: migrated statistics 10.8M rows +
# statistics_short_term 1.9M (~1.8 GB with indexes in Postgres) and ~18M
# states rows for the purge_keep_days:7 window (~4 GB).
#
# 20Gi left only 6.63 GiB free, and that is the number that matters here.
# WAL archiving stalled for 10 minutes and the un-archived backlog reached
# 1.84 GiB — 28% of that free space (REN-129).
#
# That stall was first blamed on Velero repository maintenance. It is not
# the cause: REN-136 measured seven nights and the archiver's sustained
# drain (~14 segments/min, its serial ceiling) is flat whether Kopia is
# running or not, and Kopia's nearest batch drifts across 02:03-02:24Z
# while the burst stays pinned to 02:13Z. What is real is a nightly
# producer burst — 56-119 segments queued at 02:13-02:15 UTC on all seven
# nights, against a steady-state queue of 0. Postgres cannot recycle a WAL
# segment until the archiver has shipped it, so a burst that arrives while
# archiving is stalled walks the volume toward full, and a full PGDATA
# stops the recorder outright.
#
# 32Gi takes free space to ~18.6 GiB, which puts the same 1.84 GiB backlog
# at 10% of headroom rather than 28%. In REN-136's terms: at 6.36 GiB free
# one stalled night survives and two fill the volume; ~18.6 GiB carries
# about four. Approved by the owner on REN-135.
# ceph-block has allowVolumeExpansion: true, so this grows in place.
#
# Since REN-176 WAL lives on walStorage below, so the stall headroom above
# now belongs to that volume. 32Gi stays because a PVC cannot shrink.
size: 32Gi
# WAL on its own volume (ha-pg-N-wal), approved by the owner on REN-176.
#
# PERMANENT. The CNPG webhook rejects removing walStorage once set ("walStorage
# cannot be disabled once configured"), so reverting this block fails
# admission and leaves the home-assistant Kustomization stuck. Undoing it
# means a new Cluster recovered from ha-pg-store. Adding it on 1.30.1 needs
# no re-clone: the operator creates the PVC, rolls each pod, and the instance
# manager moves pg_wal onto it before Postgres starts.
#
# This does NOT keep the recorder up when WAL fills: a full WAL disk still
# stops Postgres. What it does is keep WAL writable if PGDATA fills (a purge
# that stops running), and make WAL-volume usage a direct archiver-backlog
# signal.
#
# Sized so stall survival is no worse than the shared 32Gi gives today.
# Today: ~18.6 GiB free on PGDATA / 4.66 GiB/day of WAL = ~4.0 days.
# 1.86 GiB normal pg_wal footprint (max_wal_size 2GB)
# + 18.64 GiB four days of full archiver outage at 4.66 GiB/day
# (the nightly 56-119 segment burst, REN-136, is inside that rate)
# = 20.5 GiB -> 21Gi: (21 - 1.86) / 4.66 = ~4.1 days. 18Gi would give ~3.5,
# worse than today. RBD is thin, so the ceiling costs nothing until a stall
# fills it. The webhook requires min_wal_size < max_wal_size < this size.
walStorage:
storageClass: ceph-block
size: 21Gi
plugins:
- name: barman-cloud.cloudnative-pg.io
isWALArchiver: true
@@ -1,7 +1,6 @@
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
resources:
- backup-password-externalsecret.yaml
- pvcs.yaml
- deployment.yaml
- service.yaml
@@ -13,8 +12,9 @@ resources:
- prometheus-token-externalsecret.yaml
- config-sync-token-externalsecret.yaml
- mosquitto-bootstrap.yaml
# health broker credential: OpenBao-backed + Class-A rotated (first of the
# eight users to migrate off mosquitto-bootstrap.yaml).
# Former `health` probe credential. The broker no longer reads it (the
# probes use the cert account mosquitto-probe, REN-953); removed with its
# rotator in the REN-802 cleanup step.
- mosquitto-health-credentials-externalsecret.yaml
# open3e-int broker credential: open3e-esp32 gateway on the Vitocal internal
# CAN; OpenBao-backed + Class-A rotated.
@@ -69,6 +69,12 @@ resources:
- ha-pg-objectstore.yaml
- ha-pg-cluster.yaml
- ha-pg-scheduled-backup.yaml
# MQTT credential management (REN-802): the account controller manages the
# production broker's Dynamic Security (REN-900). mosquitto-dynsec-test is
# the step-1 test broker, no longer managed; removal follows separately.
# Register: mqtt-accounts.yaml (configMapGenerator).
- mosquitto-dynsec-test.yaml
- mqtt-account-controller.yaml
configMapGenerator:
# nginx config for the reverse-proxy sidecar. Hash suffix disabled so
# the cm name stays stable; editing proxy.conf does not auto-roll the
@@ -104,5 +110,28 @@ configMapGenerator:
namespace: home-assistant
files:
- guard.sh=zigbee2mqtt-discovery-guard.sh
# Z2M external converters, copied into /app/data/external_converters by the
# seed-data init container on every start. Hash suffix disabled (name stays
# stable), so editing a converter does not auto-roll the pod — restart
# manually with `kubectl rollout restart deploy/zigbee2mqtt -n home-assistant`.
- name: zigbee2mqtt-external-converters
namespace: home-assistant
files:
- wetterstation-ws90.js=zigbee2mqtt-ws90-converter.js
# MQTT account register, read by mqtt-account-controller on every loop.
# Hash suffix disabled (name stays stable); the volume is not a subPath
# mount, so an edit reaches the running controller without a restart.
- name: mqtt-accounts
namespace: home-assistant
files:
- mqtt-accounts.yaml
# shelly-manager api-proxy sidecar config (REN-935). Hash suffix disabled
# (name stays stable), so editing shelly-manager-api-proxy.conf does not
# auto-roll the pod — restart manually with
# `kubectl rollout restart deploy/shelly-manager -n home-assistant`.
- name: shelly-manager-api-proxy
namespace: home-assistant
files:
- api.conf.template=shelly-manager-api-proxy.conf
generatorOptions:
disableNameSuffixHash: true
@@ -42,6 +42,9 @@ spec:
labels:
app.kubernetes.io/name: mdns-relay
annotations:
# Bump to restart the pod and re-attach net1 (DHCP via multus).
# 2026-10-06: first attach on containernetworking/plugins v1.9.1.
homelab.renner.uno/restarted-for: "2026-10-06 cni-plugins v1.9.1 attach check"
k8s.v1.cni.cncf.io/networks: mdns-relay-iot
spec:
enableServiceLinks: false
@@ -82,7 +85,7 @@ spec:
# deliver, and the ClusterIP has no backend while HA restarts. The
# trap forwards SIGTERM so the pod still terminates promptly.
- name: socat-ipv4
image: alpine/socat:1.8.0.3@sha256:beb4a68d9e4fe6b0f21ea774a0fde6c31f580dde6368939ed70100c5385b015e
image: alpine/socat:1.8.1.3@sha256:82ad20f6f6e29b91ff33b6662d24063522b1378f08fd8569cd3ab412cac13f50
imagePullPolicy: IfNotPresent
command:
- /bin/sh
@@ -124,7 +127,7 @@ spec:
# depends on the kernel's bindv6only default rather than on anything
# stated here, so the roles are made explicit instead of inherited.
- name: socat-ipv6
image: alpine/socat:1.8.0.3@sha256:beb4a68d9e4fe6b0f21ea774a0fde6c31f580dde6368939ed70100c5385b015e
image: alpine/socat:1.8.1.3@sha256:82ad20f6f6e29b91ff33b6662d24063522b1378f08fd8569cd3ab412cac13f50
imagePullPolicy: IfNotPresent
command:
- /bin/sh
@@ -44,6 +44,10 @@ kind: Job
metadata:
name: mosquitto-credentials-bootstrap
namespace: home-assistant
annotations:
# Job pod templates are immutable; force-recreate so image bumps
# apply on Flux re-reconcile. Safe: the Job is idempotent (see above).
kustomize.toolkit.fluxcd.io/force: enabled
spec:
backoffLimit: 4
template:
@@ -55,7 +59,7 @@ spec:
restartPolicy: OnFailure
containers:
- name: bootstrap
image: alpine:3.21
image: alpine:3.24@sha256:294b683cb724975bec92580e1e685676bd4b50bda910ddb8c51d4cabeaec77e6
command:
- sh
- -c
@@ -112,6 +116,10 @@ kind: Job
metadata:
name: mosquitto-admin-credentials-bootstrap
namespace: home-assistant
annotations:
# Job pod templates are immutable; force-recreate so image bumps
# apply on Flux re-reconcile. Safe: the Job is idempotent (see above).
kustomize.toolkit.fluxcd.io/force: enabled
spec:
backoffLimit: 4
template:
@@ -123,7 +131,7 @@ spec:
restartPolicy: OnFailure
containers:
- name: bootstrap
image: alpine:3.21
image: alpine:3.24@sha256:294b683cb724975bec92580e1e685676bd4b50bda910ddb8c51d4cabeaec77e6
command:
- sh
- -c
@@ -179,6 +187,10 @@ kind: Job
metadata:
name: mosquitto-shellies-credentials-bootstrap
namespace: home-assistant
annotations:
# Job pod templates are immutable; force-recreate so image bumps
# apply on Flux re-reconcile. Safe: the Job is idempotent (see above).
kustomize.toolkit.fluxcd.io/force: enabled
spec:
backoffLimit: 4
template:
@@ -190,7 +202,7 @@ spec:
restartPolicy: OnFailure
containers:
- name: bootstrap
image: alpine:3.21
image: alpine:3.24@sha256:294b683cb724975bec92580e1e685676bd4b50bda910ddb8c51d4cabeaec77e6
command:
- sh
- -c
@@ -245,6 +257,10 @@ kind: Job
metadata:
name: mosquitto-sml2mqtt-credentials-bootstrap
namespace: home-assistant
annotations:
# Job pod templates are immutable; force-recreate so image bumps
# apply on Flux re-reconcile. Safe: the Job is idempotent (see above).
kustomize.toolkit.fluxcd.io/force: enabled
spec:
backoffLimit: 4
template:
@@ -256,7 +272,7 @@ spec:
restartPolicy: OnFailure
containers:
- name: bootstrap
image: alpine:3.21
image: alpine:3.24@sha256:294b683cb724975bec92580e1e685676bd4b50bda910ddb8c51d4cabeaec77e6
command:
- sh
- -c
@@ -313,6 +329,10 @@ kind: Job
metadata:
name: mosquitto-open3e-credentials-bootstrap
namespace: home-assistant
annotations:
# Job pod templates are immutable; force-recreate so image bumps
# apply on Flux re-reconcile. Safe: the Job is idempotent (see above).
kustomize.toolkit.fluxcd.io/force: enabled
spec:
backoffLimit: 4
template:
@@ -324,7 +344,7 @@ spec:
restartPolicy: OnFailure
containers:
- name: bootstrap
image: alpine:3.21
image: alpine:3.24@sha256:294b683cb724975bec92580e1e685676bd4b50bda910ddb8c51d4cabeaec77e6
command:
- sh
- -c
@@ -383,6 +403,10 @@ kind: Job
metadata:
name: mosquitto-zigbee2mqtt-credentials-bootstrap
namespace: home-assistant
annotations:
# Job pod templates are immutable; force-recreate so image bumps
# apply on Flux re-reconcile. Safe: the Job is idempotent (see above).
kustomize.toolkit.fluxcd.io/force: enabled
spec:
backoffLimit: 4
template:
@@ -394,7 +418,7 @@ spec:
restartPolicy: OnFailure
containers:
- name: bootstrap
image: alpine:3.21
image: alpine:3.24@sha256:294b683cb724975bec92580e1e685676bd4b50bda910ddb8c51d4cabeaec77e6
command:
- sh
- -c
@@ -10,3 +10,38 @@ spec:
kind: ClusterIssuer
dnsNames:
- mqtt.renner.uno
---
# Server certificate of the mutual-TLS listener :8884 (REN-802). Issued by
# mqtt-ca because certificate clients and mqtt-account-controller trust only
# that CA. The Let's Encrypt certificate above stays on :8883 for password
# clients. In-cluster names only; an outside cert client (edge-1) is REN-802
# step 3.
#
# Long-lived on purpose: mosquitto reads its certificate only at start, and a
# broker restart is an outage, so nothing restarts it for a renewal. With 2
# years and renewal after 1, the broker serves a renewed certificate after the
# next restart of any kind (image bump, node reboot) within that year; the old
# one stays valid until then.
apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
name: mosquitto-mtls
namespace: home-assistant
spec:
secretName: mosquitto-mtls
duration: 17520h
renewBefore: 8760h
dnsNames:
- mosquitto
- mosquitto.home-assistant.svc
- mosquitto.home-assistant.svc.cluster.local
usages:
- digital signature
- server auth
privateKey:
algorithm: ECDSA
size: 256
issuerRef:
group: cert-manager.io
kind: ClusterIssuer
name: mqtt-ca
@@ -64,6 +64,66 @@ data:
certfile /mosquitto/tls/tls.crt
keyfile /mosquitto/tls/tls.key
# Mutual TLS for certificate clients (REN-802). Only certificates from
# mqtt-ca are accepted, and the certificate's CN is the username. Not on
# the LoadBalancer: in-cluster only (Service `mosquitto`).
listener 8884
max_connections 200
cafile /mosquitto/mtls/ca.crt
certfile /mosquitto/mtls/tls.crt
keyfile /mosquitto/mtls/tls.key
require_certificate true
use_identity_as_username true
allow_anonymous false
# Two account sources side by side (REN-802 step 2, tested on 2.0.22 in
# REN-900, document `coexistence`):
# Dynamic Security: accounts from the register mqtt-accounts.yaml,
# managed live by mqtt-account-controller over $CONTROL.
# password_file/acl_file: the legacy users, unchanged until each client
# moves to the register (step 3).
# Dynamic Security is asked first. For a username it does not know, and
# for a request none of its roles match, it defers to the files. A
# register entry with the same name as a legacy user therefore replaces
# that user's password, while its acl_file block still applies to
# whatever the entry's roles do not cover. Delete the legacy user when
# its client moves.
#
# The acl_file check of 2.0 allows every SUBSCRIBE and checks only on
# delivery, so the Dynamic Security default must deny publishClientReceive.
# Otherwise every Dynamic Security client could read every topic.
plugin /usr/lib/mosquitto_dynamic_security.so
plugin_opt_config_file /mosquitto/auth/dynamic-security.json
password_file /mosquitto/auth/passwd
acl_file /mosquitto/auth/acl
# Dynamic Security start file, used until mqtt-account-controller has
# written the Secret mqtt-dynsec-seed. No secrets: only the controller's
# certificate client and a role that reaches the Dynamic Security API and
# nothing else.
dynamic-security.json: |
{
"defaultACLAccess": {
"publishClientSend": false,
"publishClientReceive": false,
"subscribe": false,
"unsubscribe": true
},
"clients": [
{
"username": "mqtt-account-controller",
"roles": [{"rolename": "mqtt-account-controller-admin"}]
}
],
"groups": [],
"roles": [
{
"rolename": "mqtt-account-controller-admin",
"acls": [
{"acltype": "publishClientReceive", "topic": "$CONTROL/dynamic-security/v1/#", "priority": 0, "allow": true},
{"acltype": "publishClientSend", "topic": "$CONTROL/dynamic-security/v1/#", "priority": 0, "allow": true},
{"acltype": "subscribePattern", "topic": "$CONTROL/dynamic-security/v1/#", "priority": 0, "allow": true}
]
}
]
}
@@ -12,7 +12,7 @@ metadata:
#
# Listed per-Secret rather than with the blanket auto annotation, so that
# enrolling another broker user is a visible edit to this line.
secret.reloader.stakater.com/reload: mosquitto-health-credentials,mosquitto-open3e-int-credentials
secret.reloader.stakater.com/reload: mosquitto-open3e-int-credentials
spec:
replicas: 1
strategy:
@@ -54,7 +54,7 @@ spec:
fsGroup: 1883
containers:
- name: mosquitto
# Pinned tag, auto-bumped within the 2.x line by Flux image-automation
# Pinned tag, auto-bumped within the 2.0 line by Flux image-automation
# (infrastructure/image-automation/mosquitto.yaml). The marker tells
# Flux where to write; patch/minor updates land as git commits and
# roll the broker. HA re-publishes its own discovery afterwards, but
@@ -80,7 +80,6 @@ spec:
mosquitto_passwd -b /mosquitto/auth/passwd open3e "$OPEN3E_PASSWORD"
mosquitto_passwd -b /mosquitto/auth/passwd open3e-int "$OPEN3E_INT_PASSWORD"
mosquitto_passwd -b /mosquitto/auth/passwd evcc "$EVCC_PASSWORD"
mosquitto_passwd -b /mosquitto/auth/passwd health "$HEALTH_PASSWORD"
mosquitto_passwd -b /mosquitto/auth/passwd zigbee2mqtt "$ZIGBEE2MQTT_PASSWORD"
# ACL: HA keeps full access (subscribes to everything); the
# shellies user is `readwrite shellies/#` (devices publish state
@@ -136,16 +135,6 @@ spec:
topic readwrite evcc/#
topic read energy/#
# `health` is the broker's own probe credential (see the
# liveness/readiness probes below). Scoped to health/# and
# nothing else: the probes publish a random value retained and
# read it back to prove the broker actually stores+delivers
# (not just PUBACKs) — so the user needs read AND write, but
# only under health/#. A leak can only touch the throwaway
# probe subtree that nothing else subscribes to.
user health
topic readwrite health/#
# `zigbee2mqtt` is the Zigbee2MQTT bridge (the ZHA replacement).
# Owns its own `zigbee2mqtt/#` subtree; may WRITE `homeassistant/#`
# to publish HA MQTT-discovery configs (write-only there, like the
@@ -165,8 +154,21 @@ spec:
topic write homeassistant/#
topic read homeassistant/status
EOF
chown 1883:1883 /mosquitto/auth/passwd /mosquitto/auth/acl
chmod 0600 /mosquitto/auth/passwd /mosquitto/auth/acl
# Dynamic Security start file (REN-802): the controller's seed
# if it exists, else the static base file. The seed carries
# every register account and its hash, so the broker is in the
# desired state before the first client connects. The plugin
# rewrites this file on every $CONTROL change, so the broker
# user owns it and the directory.
if [ -s /mosquitto/seed/dynamic-security.json ]; then
cp /mosquitto/seed/dynamic-security.json /mosquitto/auth/dynamic-security.json
echo "dynsec: loaded seed from Secret mqtt-dynsec-seed"
else
cp /mosquitto/config/dynamic-security.json /mosquitto/auth/dynamic-security.json
echo "dynsec: no seed yet, loaded base file"
fi
chown 1883:1883 /mosquitto/auth /mosquitto/auth/passwd /mosquitto/auth/acl /mosquitto/auth/dynamic-security.json
chmod 0600 /mosquitto/auth/passwd /mosquitto/auth/acl /mosquitto/auth/dynamic-security.json
exec mosquitto -c /mosquitto/config/mosquitto.conf
env:
- name: HA_PASSWORD
@@ -206,17 +208,6 @@ spec:
secretKeyRef:
name: mosquitto-evcc-credentials
key: password
# Probe-only credential. Now OpenBao-backed and Class-A rotated (see
# mosquitto-health-credentials-externalsecret.yaml); its bootstrap Job
# is gone.
# Present here for the same reason as the others — the startup
# shim hashes it into the passwd file — and reused by the exec
# probes below, which run inside this container.
- name: HEALTH_PASSWORD
valueFrom:
secretKeyRef:
name: mosquitto-health-credentials
key: password
# Zigbee2MQTT bridge credential (mosquitto-zigbee2mqtt-credentials-
# bootstrap). Hashed into the passwd file here; Z2M reads the same
# Secret via its init container to authenticate to the broker.
@@ -232,6 +223,9 @@ spec:
- name: mqtts
containerPort: 8883
protocol: TCP
- name: mqtts-cert
containerPort: 8884
protocol: TCP
volumeMounts:
- name: config
mountPath: /mosquitto/config
@@ -241,6 +235,15 @@ spec:
- name: tls
mountPath: /mosquitto/tls
readOnly: true
- name: mtls
mountPath: /mosquitto/mtls
readOnly: true
- name: seed
mountPath: /mosquitto/seed
readOnly: true
- name: probe-tls
mountPath: /mosquitto/probe-tls
readOnly: true
# Real MQTT round-trip probes, replacing the old tcpSocket checks.
# A bare TCP accept proved only that a listener existed. Even a
# QoS-1 PUBACK proves only that the broker acknowledged the publish
@@ -259,14 +262,14 @@ spec:
# Liveness and readiness use SEPARATE topics (probe/live vs
# probe/ready) so their rotating retained values never collide.
#
# Uses the dedicated least-privilege `health` user (ACL: readwrite
# health/# only — see the passwd/acl build above and the
# mosquitto-health-credentials ExternalSecret). Its password is in
# this container's env (HEALTH_PASSWORD) because the startup shim
# hashes every user into the passwd file; the exec probes run
# inside this container and read it directly. A leak of this
# credential can only touch the health/# probe subtree, which
# nothing else subscribes to.
# Logs in as the register account `mosquitto-probe` (mqtt-accounts.yaml,
# REN-953): a client certificate from mqtt-ca on the mTLS listener
# :8884, ACL readwrite health/# only. No password exists for it.
# The Secret mount is not a subPath, so a cert-manager renewal
# reaches the next probe without a restart. --insecure skips only
# the hostname check, because the server certificate names the
# Service and the probe dials 127.0.0.1; the chain is still checked
# against mqtt-ca.
#
# mosquitto is a single-replica SPOF (HA, Shelly, sml2mqtt, open3e,
# evcc). Liveness is deliberately slow to fire — failureThreshold 6
@@ -286,8 +289,9 @@ spec:
- -c
- |
V="probe-$(head -c8 /dev/urandom | od -An -tx1 | tr -d ' ')"
mosquitto_pub -h 127.0.0.1 -p 1883 -u health -P "$HEALTH_PASSWORD" -q 1 -r -t health/probe/ready -m "$V" &&
[ "$(mosquitto_sub -h 127.0.0.1 -p 1883 -u health -P "$HEALTH_PASSWORD" -t health/probe/ready -C 1 -W 5)" = "$V" ]
T="-h 127.0.0.1 -p 8884 --insecure --cafile /mosquitto/probe-tls/ca.crt --cert /mosquitto/probe-tls/tls.crt --key /mosquitto/probe-tls/tls.key"
mosquitto_pub $T -q 1 -r -t health/probe/ready -m "$V" &&
[ "$(mosquitto_sub $T -t health/probe/ready -C 1 -W 5)" = "$V" ]
periodSeconds: 15
timeoutSeconds: 10
failureThreshold: 3
@@ -298,8 +302,9 @@ spec:
- -c
- |
V="probe-$(head -c8 /dev/urandom | od -An -tx1 | tr -d ' ')"
mosquitto_pub -h 127.0.0.1 -p 1883 -u health -P "$HEALTH_PASSWORD" -q 1 -r -t health/probe/live -m "$V" &&
[ "$(mosquitto_sub -h 127.0.0.1 -p 1883 -u health -P "$HEALTH_PASSWORD" -t health/probe/live -C 1 -W 5)" = "$V" ]
T="-h 127.0.0.1 -p 8884 --insecure --cafile /mosquitto/probe-tls/ca.crt --cert /mosquitto/probe-tls/tls.crt --key /mosquitto/probe-tls/tls.key"
mosquitto_pub $T -q 1 -r -t health/probe/live -m "$V" &&
[ "$(mosquitto_sub $T -t health/probe/live -C 1 -W 5)" = "$V" ]
periodSeconds: 30
timeoutSeconds: 10
failureThreshold: 6
@@ -320,3 +325,23 @@ spec:
- name: tls
secret:
secretName: mosquitto-tls
# mqtt-ca server certificate and CA of the :8884 mTLS listener, read
# only at start (renewal timing: mosquitto-certificate.yaml).
- name: mtls
secret:
secretName: mosquitto-mtls
# Written by mqtt-account-controller. Optional so the broker still
# starts with the base file if the Secret is missing. Not in the
# reloader annotation: a register change is applied live over
# $CONTROL and must never restart the broker.
- name: seed
secret:
secretName: mqtt-dynsec-seed
optional: true
# Probe certificate of the register account mosquitto-probe, created
# by mqtt-account-controller. Not optional: a pod without it fails its
# probes, so it waits for the Secret instead.
- name: probe-tls
secret:
secretName: mqtt-mosquitto-probe-tls
defaultMode: 0400
@@ -0,0 +1,233 @@
# Test broker for mqtt-account-controller (REN-802 step 1, REN-888).
#
# A second, throwaway mosquitto with the Dynamic Security plugin and a mutual-
# TLS listener, so the controller can be proven (cert login, reconcile, seed
# after restart, revocation) without touching the production broker. Nothing
# in production connects here.
#
# Deliberately NOT labelled app.kubernetes.io/name: mosquitto: that label is
# the selector of the production Services and of mosquitto-world-ingress, so
# reusing it would put this pod behind mqtt.renner.uno and the IoT VLAN.
# ClusterIP only; reachable from inside the home-assistant namespace.
#
# Removal: delete this file and its kustomization.yaml entry once production
# runs Dynamic Security (REN-802 step 2).
apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
name: mosquitto-dynsec-test-tls
namespace: home-assistant
spec:
secretName: mosquitto-dynsec-test-tls
dnsNames:
- mosquitto-dynsec-test
- mosquitto-dynsec-test.home-assistant.svc
- mosquitto-dynsec-test.home-assistant.svc.cluster.local
usages:
- digital signature
- server auth
privateKey:
algorithm: ECDSA
size: 256
issuerRef:
group: cert-manager.io
kind: ClusterIssuer
name: mqtt-ca
---
apiVersion: v1
kind: ConfigMap
metadata:
name: mosquitto-dynsec-test-config
namespace: home-assistant
data:
mosquitto.conf: |
persistence false
log_dest stdout
log_type error
log_type warning
log_type notice
log_type information
# Dynamic Security owns authentication and ACLs. The plugin writes its
# state back to this file; it is an emptyDir, refilled by the
# initContainer on every start.
plugin /usr/lib/mosquitto_dynamic_security.so
plugin_opt_config_file /mosquitto/dynsec/dynamic-security.json
# Mutual TLS only. The client certificate's CN is the username; the
# Dynamic Security client of that name supplies the roles.
listener 8883
cafile /mosquitto/tls/ca.crt
certfile /mosquitto/tls/tls.crt
keyfile /mosquitto/tls/tls.key
require_certificate true
use_identity_as_username true
allow_anonymous false
# Start file used until the controller has written the Secret
# mqtt-dynsec-seed. No secrets: only the controller's certificate client
# and a role that reaches the Dynamic Security API and nothing else. Same
# shape as the controller's seed renderer (internal/dynsec/config.go).
dynamic-security.json: |
{
"defaultACLAccess": {
"publishClientSend": false,
"publishClientReceive": true,
"subscribe": false,
"unsubscribe": true
},
"clients": [
{
"username": "mqtt-account-controller",
"roles": [{"rolename": "mqtt-account-controller-admin"}]
}
],
"groups": [],
"roles": [
{
"rolename": "mqtt-account-controller-admin",
"acls": [
{"acltype": "publishClientReceive", "topic": "$CONTROL/dynamic-security/v1/#", "priority": 0, "allow": true},
{"acltype": "publishClientSend", "topic": "$CONTROL/dynamic-security/v1/#", "priority": 0, "allow": true},
{"acltype": "subscribePattern", "topic": "$CONTROL/dynamic-security/v1/#", "priority": 0, "allow": true}
]
}
]
}
---
apiVersion: apps/v1
kind: Deployment
metadata:
name: mosquitto-dynsec-test
namespace: home-assistant
labels:
app.kubernetes.io/name: mosquitto-dynsec-test
spec:
replicas: 1
strategy:
type: Recreate
selector:
matchLabels:
app.kubernetes.io/name: mosquitto-dynsec-test
template:
metadata:
labels:
app.kubernetes.io/name: mosquitto-dynsec-test
spec:
automountServiceAccountToken: false
terminationGracePeriodSeconds: 10
# Runs as the mosquitto UID from the start instead of starting as root
# and dropping, so the dynsec file the initContainer writes is the
# broker's own.
securityContext:
runAsNonRoot: true
runAsUser: 1883
runAsGroup: 1883
fsGroup: 1883
seccompProfile:
type: RuntimeDefault
initContainers:
# Every start: the controller's seed if it exists, else the static
# base file. The seed carries every account and password hash, so the
# broker is in the desired state before the first client connects.
- name: dynsec-seed
image: eclipse-mosquitto:2.0.22 # {"$imagepolicy": "flux-system:mosquitto"}
command:
- sh
- -c
- |
set -eu
if [ -s /seed/dynamic-security.json ]; then
cp /seed/dynamic-security.json /mosquitto/dynsec/dynamic-security.json
echo "dynsec: loaded seed from Secret mqtt-dynsec-seed"
else
cp /mosquitto/config/dynamic-security.json /mosquitto/dynsec/dynamic-security.json
echo "dynsec: no seed yet, loaded base file"
fi
chmod 0600 /mosquitto/dynsec/dynamic-security.json
securityContext:
allowPrivilegeEscalation: false
readOnlyRootFilesystem: true
capabilities:
drop: ["ALL"]
volumeMounts:
- name: config
mountPath: /mosquitto/config
readOnly: true
- name: seed
mountPath: /seed
readOnly: true
- name: dynsec
mountPath: /mosquitto/dynsec
containers:
- name: mosquitto
# Same tag and image policy as the production broker, so the test
# runs the version that production will run.
image: eclipse-mosquitto:2.0.22 # {"$imagepolicy": "flux-system:mosquitto"}
command: ["mosquitto", "-c", "/mosquitto/config/mosquitto.conf"]
ports:
- name: mqtts
containerPort: 8883
protocol: TCP
securityContext:
allowPrivilegeEscalation: false
readOnlyRootFilesystem: true
capabilities:
drop: ["ALL"]
volumeMounts:
- name: config
mountPath: /mosquitto/config
readOnly: true
- name: tls
mountPath: /mosquitto/tls
readOnly: true
- name: dynsec
mountPath: /mosquitto/dynsec
readinessProbe:
tcpSocket:
port: mqtts
periodSeconds: 10
livenessProbe:
tcpSocket:
port: mqtts
periodSeconds: 30
failureThreshold: 6
resources:
requests:
cpu: 5m
memory: 16Mi
limits:
memory: 64Mi
volumes:
- name: config
configMap:
name: mosquitto-dynsec-test-config
- name: tls
secret:
secretName: mosquitto-dynsec-test-tls
# Written by mqtt-account-controller. Optional: absent on the very
# first start, when the base file is used instead.
- name: seed
secret:
secretName: mqtt-dynsec-seed
optional: true
- name: dynsec
emptyDir:
sizeLimit: 4Mi
---
apiVersion: v1
kind: Service
metadata:
name: mosquitto-dynsec-test
namespace: home-assistant
labels:
app.kubernetes.io/name: mosquitto-dynsec-test
spec:
type: ClusterIP
selector:
app.kubernetes.io/name: mosquitto-dynsec-test
ports:
- name: mqtts
port: 8883
targetPort: mqtts
protocol: TCP
@@ -12,3 +12,7 @@ spec:
- name: mqtt
port: 1883
targetPort: mqtt
# Mutual TLS for certificate clients and mqtt-account-controller (REN-802).
- name: mqtts-cert
port: 8884
targetPort: mqtts-cert
@@ -0,0 +1,317 @@
# mqtt-account-controller (REN-802, code REN-837, deploy REN-888).
# Source: konairius/mqtt-account-controller (maintainer Hephaestus). Reconciles
# the broker's Dynamic Security clients/roles/ACLs, the cert-manager
# Certificates of `auth: cert` accounts and device passwords to the register
# mqtt-accounts.yaml, every INTERVAL (2m).
#
# Manages the production broker `mosquitto` over its mTLS listener :8884
# (REN-802 step 2, REN-900). The legacy users in that broker's password_file
# are not Dynamic Security clients, so the controller never sees or touches
# them.
apiVersion: v1
kind: ServiceAccount
metadata:
name: mqtt-account-controller
namespace: home-assistant
labels:
app.kubernetes.io/name: mqtt-account-controller
---
# Find the Certificates it manages (label app.kubernetes.io/managed-by=
# mqtt-account-controller) in every namespace. List only: no get, watch or
# write cluster-wide.
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: mqtt-account-controller-list-certificates
labels:
app.kubernetes.io/name: mqtt-account-controller
rules:
- apiGroups: ["cert-manager.io"]
resources: ["certificates"]
verbs: ["list"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
name: mqtt-account-controller-list-certificates
labels:
app.kubernetes.io/name: mqtt-account-controller
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole
name: mqtt-account-controller-list-certificates
subjects:
- kind: ServiceAccount
name: mqtt-account-controller
namespace: home-assistant
---
# Per deliver.namespace: manage the account Certificates there (server-side
# apply = patch, which creates through `create`). One Role + RoleBinding per
# namespace that appears as `deliver.namespace` in the register: home-assistant,
# evcc and paperclip.
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
name: mqtt-account-controller-certificates
namespace: home-assistant
labels:
app.kubernetes.io/name: mqtt-account-controller
rules:
- apiGroups: ["cert-manager.io"]
resources: ["certificates"]
verbs: ["get", "create", "patch", "delete"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: mqtt-account-controller-certificates
namespace: home-assistant
labels:
app.kubernetes.io/name: mqtt-account-controller
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: Role
name: mqtt-account-controller-certificates
subjects:
- kind: ServiceAccount
name: mqtt-account-controller
namespace: home-assistant
---
# Secrets in home-assistant, by name only. This namespace holds every broker
# and HA credential, so an unnamed `delete secrets` grant would let the
# controller wipe all of them.
# mqtt-account-hashes, mqtt-dynsec-seed: its own state (server-side apply
# creates them, hence create + patch; resourceNames hold for an apply
# that creates, because the name is in the request path).
# mqtt-<name>-tls: delete on revocation, one entry per cert account
# delivered to this namespace. Add the name with the register entry.
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
name: mqtt-account-controller-secrets-home-assistant
namespace: home-assistant
labels:
app.kubernetes.io/name: mqtt-account-controller
rules:
- apiGroups: [""]
resources: ["secrets"]
resourceNames: ["mqtt-account-hashes", "mqtt-dynsec-seed"]
verbs: ["get", "create", "patch"]
- apiGroups: [""]
resources: ["secrets"]
resourceNames:
- mqtt-test-cert-tls
- mqtt-mosquitto-probe-tls
- mqtt-zigbee2mqtt-bridge-tls
- mqtt-home-assistant-tls
verbs: ["delete"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: mqtt-account-controller-secrets-home-assistant
namespace: home-assistant
labels:
app.kubernetes.io/name: mqtt-account-controller
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: Role
name: mqtt-account-controller-secrets-home-assistant
subjects:
- kind: ServiceAccount
name: mqtt-account-controller
namespace: home-assistant
---
# deliver.namespace evcc (account evcc-client): its Certificate, and its
# Secret by name for revocation.
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
name: mqtt-account-controller-certificates
namespace: evcc
labels:
app.kubernetes.io/name: mqtt-account-controller
rules:
- apiGroups: ["cert-manager.io"]
resources: ["certificates"]
verbs: ["get", "create", "patch", "delete"]
- apiGroups: [""]
resources: ["secrets"]
resourceNames:
- mqtt-evcc-client-tls
verbs: ["delete"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: mqtt-account-controller-certificates
namespace: evcc
labels:
app.kubernetes.io/name: mqtt-account-controller
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: Role
name: mqtt-account-controller-certificates
subjects:
- kind: ServiceAccount
name: mqtt-account-controller
namespace: home-assistant
---
# deliver.namespace paperclip (account agents-read): its Certificate, and its
# Secret by name for revocation.
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
name: mqtt-account-controller-certificates
namespace: paperclip
labels:
app.kubernetes.io/name: mqtt-account-controller
rules:
- apiGroups: ["cert-manager.io"]
resources: ["certificates"]
verbs: ["get", "create", "patch", "delete"]
- apiGroups: [""]
resources: ["secrets"]
resourceNames:
- mqtt-agents-read-tls
verbs: ["delete"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
name: mqtt-account-controller-certificates
namespace: paperclip
labels:
app.kubernetes.io/name: mqtt-account-controller
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: Role
name: mqtt-account-controller-certificates
subjects:
- kind: ServiceAccount
name: mqtt-account-controller
namespace: home-assistant
---
# The controller's own MQTT identity: CN = Dynamic Security admin client
# (ADMIN_USER). Not labelled managed-by, so the controller never treats it
# as an account certificate and never revokes it. Re-read on every TLS
# handshake, so a renewal needs no restart.
apiVersion: cert-manager.io/v1
kind: Certificate
metadata:
name: mqtt-account-controller
namespace: home-assistant
spec:
secretName: mqtt-account-controller-tls
commonName: mqtt-account-controller
usages:
- digital signature
- client auth
privateKey:
algorithm: ECDSA
size: 256
rotationPolicy: Always
issuerRef:
group: cert-manager.io
kind: ClusterIssuer
name: mqtt-ca
---
apiVersion: apps/v1
kind: Deployment
metadata:
name: mqtt-account-controller
namespace: home-assistant
labels:
app.kubernetes.io/name: mqtt-account-controller
annotations:
# The controller reads the shelly-manager API key once at start; the
# quarterly rotation of shelly-manager-auth must restart it too.
secret.reloader.stakater.com/reload: shelly-manager-auth
spec:
replicas: 1
# One writer at a time: two controllers would race on rotations and the
# seed Secret.
strategy:
type: Recreate
selector:
matchLabels:
app.kubernetes.io/name: mqtt-account-controller
template:
metadata:
labels:
app.kubernetes.io/name: mqtt-account-controller
spec:
serviceAccountName: mqtt-account-controller
securityContext:
runAsNonRoot: true
runAsUser: 65532
runAsGroup: 65532
seccompProfile:
type: RuntimeDefault
containers:
- name: controller
# Woodpecker builds main-<sha> on every merge to main; no sortable
# tag, so bumps are manual (same as ical-proxy).
image: gitea.renner.uno/konairius/mqtt-account-controller:main-982231a@sha256:851dd025a8aea352061ac818f9968e1c4a074c8f33af405efde3424382e77ae1
env:
- name: BROKER_URL
value: ssl://mosquitto.home-assistant.svc.cluster.local:8884
# Password push to Shellies (accounts with deliver.shelly-manager).
# The API-key-only Service (api-proxy sidecar, :8081), like the
# agents; same namespace, so the default-deny allows it.
- name: SHELLY_MANAGER_URL
value: http://shelly-manager-api.home-assistant.svc.cluster.local
- name: SHELLY_MANAGER_API_KEY_FILE
value: /etc/shelly-manager/api-key
# Not :8080: several :8080 ingress grants in the home-assistant
# default-deny apply to every pod in the namespace.
- name: LISTEN
value: ":8081"
ports:
- name: http
containerPort: 8081
protocol: TCP
# /healthz is 200 while a reconcile succeeded within 3 x INTERVAL.
# Readiness only: a restart does not fix an unreachable broker.
readinessProbe:
httpGet:
path: /healthz
port: http
periodSeconds: 30
securityContext:
allowPrivilegeEscalation: false
readOnlyRootFilesystem: true
capabilities:
drop: ["ALL"]
volumeMounts:
- name: register
mountPath: /etc/mqtt-accounts
readOnly: true
- name: tls
mountPath: /etc/mqtt-tls
readOnly: true
- name: shelly-manager-key
mountPath: /etc/shelly-manager
readOnly: true
resources:
requests:
cpu: 5m
memory: 16Mi
limits:
memory: 64Mi
volumes:
# Not a subPath mount, so a register change reaches the running pod
# (kubelet sync, ~1 min) and the next loop reads it without a restart.
- name: register
configMap:
name: mqtt-accounts
- name: tls
secret:
secretName: mqtt-account-controller-tls
# Only the api-key item, not the shelly-manager admin password.
- name: shelly-manager-key
secret:
secretName: shelly-manager-auth
items:
- key: api-key
path: api-key
@@ -0,0 +1,206 @@
# MQTT account register (REN-802). The only definition of who may use the
# broker: mqtt-account-controller reconciles certificates, device passwords
# and Dynamic Security clients/roles/ACLs to this list. Format: README of
# konairius/mqtt-account-controller.
#
# Delivered to the controller as the ConfigMap `mqtt-accounts` (see the
# configMapGenerator in kustomization.yaml). An empty list is refused, so it
# never revokes everyone.
#
# The controller manages the production broker `mosquitto` (REN-900). Its
# legacy users (password_file in mosquitto-deployment.yaml) are not listed
# here; each moves here with its client (REN-802 step 3). `test-cert` is the
# certificate test account from REN-888.
#
# A cert account needs its Secret `mqtt-<name>-tls` added to the
# `mqtt-account-controller-secrets-<namespace>` Role in
# mqtt-account-controller.yaml, or revoking it fails with 403.
- name: test-cert
auth: cert
deliver: {namespace: home-assistant}
acl: ["readwrite test/cert/#"]
# The broker's own liveness/readiness probe (mosquitto-deployment.yaml).
# Not named `health`: a Dynamic Security client of that name would shadow the
# legacy password user while the old broker pod still probes with it.
- name: mosquitto-probe
auth: cert
deliver: {namespace: home-assistant}
acl: ["readwrite health/#"]
# Zigbee2MQTT and its two sidecars (discovery-guard, interview-watch), one
# certificate for the pod. Same ACL as the legacy user `zigbee2mqtt`; not
# named like it, so this entry cannot shadow the password login of a running
# Z2M (REN-953).
- name: zigbee2mqtt-bridge
auth: cert
deliver: {namespace: home-assistant}
acl: ["readwrite zigbee2mqtt/#", "write homeassistant/#", "read homeassistant/status"]
# evcc (evcc namespace). Same ACL as the legacy user `evcc`, different name
# so it cannot shadow the running password login (REN-953). evcc takes the
# certificate PEMs by env (EVCC_MQTT_*), see apps/evcc/deployment.yaml.
- name: evcc-client
auth: cert
deliver: {namespace: evcc}
acl: ["read open3e/#", "readwrite evcc/#", "read energy/#"]
# Home Assistant, via the ghostunnel sidecar `mqtt-tls` in its pod (HA keeps
# client certificates only as uploaded PEMs in its config entry, so a renewal
# could not reach it without a reconfigure). Same ACL as the legacy user
# `homeassistant`; not named like it, so it cannot shadow that login (REN-953).
- name: home-assistant
auth: cert
deliver: {namespace: home-assistant}
acl: ["readwrite #"]
# Read-only account for agents (REN-953). One account for all of them: the
# agents share sandboxes, so per-agent separation would be nominal. The
# Secret lands in `paperclip`; agents fetch it per run with their kubectl
# identity (Role mqtt-agents-read in apps/paperclip/agent-kubectl-rbac.yaml),
# so a renewal needs no restart. Network path: agent sandbox pods ->
# mosquitto :8884 only.
- name: agents-read
auth: cert
deliver: {namespace: paperclip}
acl: ["read open3e/#", "read zigbee2mqtt/#", "read homeassistant/#"]
# Shellies (REN-1017): one password account per device, pushed by the
# controller through shelly-manager's per-device API. Name shelly-<id> =
# shelly-manager device id. Same ACL as the legacy user `shellies`, which
# keeps working until every device has moved. Gen2+ devices reboot once
# when their password is pushed.
- name: shelly-5 # Plus i4, the API test device of REN-929
auth: password
deliver: {shelly-manager: 5}
acl: ["readwrite shellies/#", "write homeassistant/#"]
# Only devices that log in as `shellies` today. A device with MQTT off never
# reports connected, so the controller would push (and reboot it) again
# every ROTATE_GRACE.
- name: shelly-6
auth: password
deliver: {shelly-manager: 6} # Plus i4 90380c3808b8
acl: ["readwrite shellies/#", "write homeassistant/#"]
- name: shelly-29
auth: password
deliver: {shelly-manager: 29} # Plus i4 b8d61a8c7f24
acl: ["readwrite shellies/#", "write homeassistant/#"]
- name: shelly-3
auth: password
deliver: {shelly-manager: 3} # Pro 3EM ac15186d43c0
acl: ["readwrite shellies/#", "write homeassistant/#"]
- name: shelly-42
auth: password
deliver: {shelly-manager: 42} # 3EM-63 G3 d885ac1c5ab4
acl: ["readwrite shellies/#", "write homeassistant/#"]
- name: shelly-43
auth: password
deliver: {shelly-manager: 43} # 3EM-63 G3 d885ac1ab274
acl: ["readwrite shellies/#", "write homeassistant/#"]
- name: shelly-10
auth: password
deliver: {shelly-manager: 10} # Plug S Gen1 4382e5
acl: ["readwrite shellies/#", "write homeassistant/#"]
- name: shelly-22
auth: password
deliver: {shelly-manager: 22} # Plug S Gen1 87e961
acl: ["readwrite shellies/#", "write homeassistant/#"]
- name: shelly-25
auth: password
deliver: {shelly-manager: 25} # Plug S Gen1 1c1a8f
acl: ["readwrite shellies/#", "write homeassistant/#"]
- name: shelly-15
auth: password
deliver: {shelly-manager: 15} # Plug S G3 8cbfea910578
acl: ["readwrite shellies/#", "write homeassistant/#"]
- name: shelly-16
auth: password
deliver: {shelly-manager: 16} # Plug S G3 b08184a63ef0
acl: ["readwrite shellies/#", "write homeassistant/#"]
- name: shelly-14
auth: password
deliver: {shelly-manager: 14} # Plus 1PM Mini 348518e0be40
acl: ["readwrite shellies/#", "write homeassistant/#"]
- name: shelly-27
auth: password
deliver: {shelly-manager: 27} # Plus 1PM Mini 348518e06c04
acl: ["readwrite shellies/#", "write homeassistant/#"]
- name: shelly-13
auth: password
deliver: {shelly-manager: 13} # Plus 2PM 48551997e624
acl: ["readwrite shellies/#", "write homeassistant/#"]
- name: shelly-19
auth: password
deliver: {shelly-manager: 19} # Plus 2PM 48551999a790
acl: ["readwrite shellies/#", "write homeassistant/#"]
- name: shelly-21
auth: password
deliver: {shelly-manager: 21} # Plus 2PM 0cdc7efa8d00
acl: ["readwrite shellies/#", "write homeassistant/#"]
- name: shelly-34
auth: password
deliver: {shelly-manager: 34} # Plus 2PM 3ce90e2f2d7c
acl: ["readwrite shellies/#", "write homeassistant/#"]
- name: shelly-2
auth: password
deliver: {shelly-manager: 2} # Wall Display 00082266e106
# Checked but never rotated on "device not connected" (REN-1066).
rotate: false
acl: ["readwrite shellies/#", "write homeassistant/#"]
- name: shelly-26
auth: password
deliver: {shelly-manager: 26} # Power Strip G4 206ef102a6cc
acl: ["readwrite shellies/#", "write homeassistant/#"]
- name: shelly-1
auth: password
deliver: {shelly-manager: 1} # Pro 4PM 9454c5b9c954
acl: ["readwrite shellies/#", "write homeassistant/#"]
- name: shelly-4
auth: password
deliver: {shelly-manager: 4} # Pro 4PM ac15186ca578
acl: ["readwrite shellies/#", "write homeassistant/#"]
- name: shelly-32
auth: password
deliver: {shelly-manager: 32} # Pro 4PM 30c6f7834ec4
acl: ["readwrite shellies/#", "write homeassistant/#"]
- name: shelly-33
auth: password
deliver: {shelly-manager: 33} # Pro 3 fce8c0db5f28
acl: ["readwrite shellies/#", "write homeassistant/#"]
# HiluX DS8: HA drives them over MQTT only, and their firmware can hang in
# the MQTT reconnect path until a power cycle (wiki
# shelly-hilux-ds8-mqtt-reconnect-hang-bug). One unit at a time; 12 is a
# bathroom mesh receiver, so its wall switch works without MQTT.
- name: shelly-12
auth: password
deliver: {shelly-manager: 12} # HiluX DS8 34b7da890cfc, Bad Spiegel Rechts
acl: ["readwrite shellies/#", "write homeassistant/#"]
- name: shelly-9
auth: password
deliver: {shelly-manager: 9} # HiluX DS8 34b7da8c03d0, Bad Badewanne
acl: ["readwrite shellies/#", "write homeassistant/#"]
- name: shelly-31
auth: password
deliver: {shelly-manager: 31} # HiluX DS8 34b7da888050, Bad Spiegel Links
acl: ["readwrite shellies/#", "write homeassistant/#"]
- name: shelly-44
auth: password
deliver: {shelly-manager: 44} # HiluX DS8 34b7da894604, Toilette (standalone, no mesh)
acl: ["readwrite shellies/#", "write homeassistant/#"]
# Sleeping H&Ts (REN-1107): awake only 8-13 s every 1-2 h, so the
# controller pushes when the device publishes `online` on its wake topic
# (shelly-manager topic prefix `shellies/<hostname>`), not in the 2-min loop.
- name: shelly-35
auth: password
deliver: {shelly-manager: 35} # Plus H&T 08b61fcea690
wake: shellies/shellyplusht-08b61fcea690/online
acl: ["readwrite shellies/#", "write homeassistant/#"]
- name: shelly-36
auth: password
deliver: {shelly-manager: 36} # Plus H&T 08b61fce90dc
wake: shellies/shellyplusht-08b61fce90dc/online
acl: ["readwrite shellies/#", "write homeassistant/#"]
- name: shelly-37
auth: password
deliver: {shelly-manager: 37} # H&T G3 84fce63ab4d8
wake: shellies/shellyhtg3-84fce63ab4d8/online
acl: ["readwrite shellies/#", "write homeassistant/#"]
- name: shelly-38
auth: password
deliver: {shelly-manager: 38} # H&T G3 ecda3bc0b6a0
wake: shellies/shellyhtg3-ecda3bc0b6a0/online
acl: ["readwrite shellies/#", "write homeassistant/#"]
@@ -0,0 +1,30 @@
# API-key-only listener for shelly-manager (REN-931, REN-935). Rendered by the
# nginx-unprivileged entrypoint (envsubst, filtered to POD_IP) into
# /etc/nginx/conf.d/ at start.
#
# shelly-manager signs in whoever X-authentik-username names when the peer is
# in Auth__ReverseProxy__TrustedProxies (the pod CIDR). Only the Authentik
# outpost may reach :8080 directly. Paperclip agent pods reach this :8081
# instead, which drops the identity header, so every request here falls through
# to the API key (or the login cookie) and a forged header gets 401.
#
# Bound to ${POD_IP}, not 0.0.0.0, so it stays off the net1 macvlan (see the
# ASPNETCORE_URLS comment in shelly-manager-deployment.yaml).
server {
listen ${POD_IP}:8081;
server_tokens off;
client_max_body_size 64m;
location / {
proxy_pass http://${POD_IP}:8080;
proxy_http_version 1.1;
proxy_set_header Host $host;
# Empty value = nginx does not pass the header at all, whatever the
# client's case or how many copies it sent. X-Forwarded-User is the
# app's default HeaderName, dropped too in case the setting changes.
# Header names with underscores never pass (ignore_invalid_headers).
proxy_set_header X-authentik-username "";
proxy_set_header X-Forwarded-User "";
proxy_read_timeout 300s;
}
}
@@ -61,7 +61,7 @@ spec:
type: RuntimeDefault
containers:
- name: shelly-manager
image: gitea.renner.uno/k.renner/shelly-manager:build.1784957186 # {"$imagepolicy": "flux-system:shelly-manager"}
image: gitea.renner.uno/k.renner/shelly-manager:build.1791385485 # {"$imagepolicy": "flux-system:shelly-manager"}
imagePullPolicy: IfNotPresent
ports:
- name: http
@@ -121,7 +121,9 @@ spec:
# outpost pod's address is dynamic, so this trusts the cluster pod
# CIDR and leans on the namespace CNP to keep other pods off the
# app port. ADMIN_PASSWORD (above) stays as break-glass, e.g. for
# port-forward access when authentik is down.
# port-forward access when authentik is down. Never open :8080 to
# another client: they get the api-proxy sidecar's :8081 (below),
# which drops the header (REN-935).
- name: Auth__ReverseProxy__Enabled
value: "true"
- name: Auth__ReverseProxy__HeaderName
@@ -168,7 +170,62 @@ spec:
memory: 128Mi
limits:
memory: 512Mi
# API-key-only listener for clients other than the Authentik outpost
# (Paperclip agents, REN-931). nginx on ${POD_IP}:8081 proxies to
# :8080 and drops X-authentik-username, so the ProxyHeader sign-in
# cannot be reached through it. Config and reasoning:
# shelly-manager-api-proxy.conf. Service: shelly-manager-api.
# No probes: it only serves the agent path, and a probe failure would
# also pull the outpost's endpoint out of the shelly-manager Service.
- name: api-proxy
image: nginxinc/nginx-unprivileged:1.31-alpine@sha256:26b0bf6fbf07297983cb341998d79c831508787de26627dd2a112321b9c3a4af
env:
- name: POD_IP
valueFrom:
fieldRef:
fieldPath: status.podIP
- name: NGINX_ENVSUBST_FILTER
value: "^POD_IP$"
ports:
- name: api
containerPort: 8081
protocol: TCP
securityContext:
runAsNonRoot: true
runAsUser: 101
runAsGroup: 101
allowPrivilegeEscalation: false
readOnlyRootFilesystem: true
capabilities:
drop: ["ALL"]
resources:
requests:
cpu: 10m
memory: 16Mi
limits:
memory: 64Mi
volumeMounts:
- name: api-proxy-config
mountPath: /etc/nginx/templates
readOnly: true
# envsubst output of the template above.
- name: api-proxy-conf-d
mountPath: /etc/nginx/conf.d
# pid file and proxy temp paths of the unprivileged image.
- name: api-proxy-tmp
mountPath: /tmp
volumes:
- name: data
persistentVolumeClaim:
claimName: shelly-manager-data
- name: api-proxy-config
configMap:
name: shelly-manager-api-proxy
- name: api-proxy-conf-d
emptyDir:
medium: Memory
sizeLimit: 1Mi
- name: api-proxy-tmp
emptyDir:
medium: Memory
sizeLimit: 32Mi
@@ -11,3 +11,21 @@ spec:
port: 80
targetPort: http
protocol: TCP
---
# API-key-only entry for Paperclip agent pods (REN-931, REN-935): the
# api-proxy sidecar, which drops the X-authentik-username header. Agents call
# http://shelly-manager-api.home-assistant.svc/api/v1/... with the API key.
# The CNPs admit agents to :8081 only; :8080 stays outpost-only.
apiVersion: v1
kind: Service
metadata:
name: shelly-manager-api
namespace: home-assistant
spec:
selector:
app.kubernetes.io/name: shelly-manager
ports:
- name: http
port: 80
targetPort: api
protocol: TCP
@@ -11,11 +11,11 @@ data:
# config once the PVC has been seeded — change the on-PVC file (via the Z2M
# frontend or an edit) instead. Kept here so a fresh PVC comes up configured.
#
# Secrets are NOT in this file: both the MQTT password and the Zigbee
# network_key are quoted parseValueRefs (`"!secret <key>"`) resolved from
# /app/data/secret.yaml, which the init container renders — the MQTT password
# from the broker-credential Secret, and the network_key extracted from the
# OpenBao coordinator backup. The non-secret network params (channel/pan_id/
# Secrets are NOT in this file: the Zigbee network_key is a quoted
# parseValueRef (`"!secret <key>"`) resolved from /app/data/secret.yaml,
# which the init container renders from the OpenBao coordinator backup. MQTT
# uses the client certificate mounted at /mqtt-tls (REN-953); the Deployment
# also sets the mqtt server/ca/cert/key by env, which wins over this file. The non-secret network params (channel/pan_id/
# ext_pan_id) are in `advanced` below.
configuration.yaml: |
# Home Assistant MQTT discovery — Z2M publishes device configs under the
@@ -32,14 +32,12 @@ data:
mqtt:
base_topic: zigbee2mqtt
server: mqtt://mosquitto:1883
user: zigbee2mqtt
# MUST be a QUOTED string: Z2M reads secrets via parseValueRef on the
# string value (regex `!<file> <key>`), NOT a YAML `!secret` tag. Unquoted
# `!secret ...` is parsed as a tag and throws "unknown scalar tag
# !<!secret>". The init container renders /app/data/secret.yaml with
# `mqtt_password` from the broker-credential Secret.
password: "!secret mqtt_password"
# Mutual TLS: the broker takes the username from the certificate CN
# (zigbee2mqtt-bridge), so no user or password here.
server: mqtts://mosquitto:8884
ca: /mqtt-tls/ca.crt
cert: /mqtt-tls/tls.crt
key: /mqtt-tls/tls.key
# SMLIGHT SLZB-06 (Texas Instruments CC2652, zigpy-znp under ZHA) reached
# over TCP on the IoT VLAN — the SAME coordinator ZHA uses today
@@ -32,9 +32,11 @@ spec:
# backup also handles the ZHA<->Z2M ext_pan_id byte-order reversal —
# which is why we restore a backup rather than hand-set advanced.ext_pan_id).
# Renders /app/data/secret.yaml (referenced by the config as quoted
# "!secret" parseValueRefs) with the MQTT password AND the Zigbee
# network_key, the latter extracted from the OpenBao coordinator backup
# as a natural-byte-order int array.
# "!secret" parseValueRefs) with the Zigbee network_key, extracted from
# the OpenBao coordinator backup as a natural-byte-order int array. No
# MQTT password since REN-953: `mqtt_password` is absent, so Z2M's
# "!secret mqtt_password" resolves to nothing and it logs in by
# certificate alone.
- name: seed-data
# Our own alpine + jq image, built by build-ci-images.yml. DATED tag,
# never :latest — rebuilding this base for an unrelated consumer
@@ -114,7 +116,6 @@ spec:
# hex key "fe0b..2d" -> "0xfe,0x0b,..,0x2d" (natural order)
NK=$(printf '%s' "$KEY" | sed 's/../0x&,/g; s/,$//')
cat > /app/data/secret.yaml <<EOF
mqtt_password: "${MQTT_PASSWORD}"
network_key: [${NK}]
EOF
if [ ! -f /app/data/configuration.yaml ]; then
@@ -132,12 +133,13 @@ spec:
else
echo "existing Z2M state present; NOT touching coordinator_backup.json"
fi
env:
- name: MQTT_PASSWORD
valueFrom:
secretKeyRef:
name: mosquitto-zigbee2mqtt-credentials
key: password
# External converters: overwritten from git on EVERY start (not
# seed-only). Copied rather than mounted because Z2M writes a temp
# copy of each converter into this directory while loading it
# (dist/extension/externalJS.js), which a read-only mount refuses.
mkdir -p /app/data/external_converters
cp /external-converters/*.js /app/data/external_converters/
echo "copied external converters: $(ls /external-converters)"
volumeMounts:
- name: data
mountPath: /app/data
@@ -147,6 +149,9 @@ spec:
- name: coordinator-backup
mountPath: /backup
readOnly: true
- name: external-converters
mountPath: /external-converters
readOnly: true
resources:
requests:
cpu: 10m
@@ -158,19 +163,36 @@ spec:
# Pinned tag. No Flux image-automation marker yet (unlike mosquitto) —
# add an infrastructure/image-automation/zigbee2mqtt.yaml policy as a
# follow-up if desired; pinned-and-manual is fine for the initial cutover.
image: ghcr.io/koenkk/zigbee2mqtt:2.13.0
image: ghcr.io/koenkk/zigbee2mqtt:2.14.2@sha256:addbfb08fcef2e4477de1535636118241e10d13e898fbe4d9faba8a4d7396311
imagePullPolicy: IfNotPresent
env:
- name: TZ
value: Europe/Berlin
- name: ZIGBEE2MQTT_DATA
value: /app/data
# MQTT by client certificate (register account zigbee2mqtt-bridge,
# REN-953). Env, not the seed template: configuration.yaml on the
# PVC is Z2M's own and is never re-seeded. Z2M copies env values
# into that file on its next settings write, so a rollback must
# set these to the old values, not just drop them. The file keeps
# `user: zigbee2mqtt`; the broker ignores it and uses the CN.
- name: ZIGBEE2MQTT_CONFIG_MQTT_SERVER
value: mqtts://mosquitto:8884
- name: ZIGBEE2MQTT_CONFIG_MQTT_CA
value: /mqtt-tls/ca.crt
- name: ZIGBEE2MQTT_CONFIG_MQTT_CERT
value: /mqtt-tls/tls.crt
- name: ZIGBEE2MQTT_CONFIG_MQTT_KEY
value: /mqtt-tls/tls.key
ports:
- name: http
containerPort: 8080
volumeMounts:
- name: data
mountPath: /app/data
- name: mqtt-tls
mountPath: /mqtt-tls
readOnly: true
# The frontend only serves once Z2M has started its adapter+MQTT, so
# an HTTP 200 on / is a decent liveness/readiness signal. Generous
# startup budget covers coordinator connect + herdsman network adopt.
@@ -194,12 +216,15 @@ spec:
periodSeconds: 30
timeoutSeconds: 5
failureThreshold: 4
# Node sizes the V8 heap from this limit: 512Mi gave a 259 MB heap,
# and Z2M died on "JavaScript heap out of memory" (exit 134) at
# 2026-09-28 17:56Z and 2026-09-29 07:36Z.
resources:
requests:
cpu: 50m
memory: 128Mi
memory: 256Mi
limits:
memory: 512Mi
memory: 1Gi
# Fires a forced interview whenever a still-un-interviewed device
# transmits — i.e. at the only moment a sleepy battery device can
# actually complete one. Z2M itself only retries interviews on a ZDO
@@ -226,19 +251,16 @@ spec:
imagePullPolicy: IfNotPresent
command: [sh, /script/watch.sh]
env:
- name: MQTT_PASSWORD
valueFrom:
secretKeyRef:
name: mosquitto-zigbee2mqtt-credentials
key: password
# These three must track zigbee2mqtt-config.yaml: MQTT_HOST the
# mosquitto Service name, MQTT_USER and BASE_TOPIC the mqtt.user and
# mqtt.base_topic it connects with. Set explicitly rather than left
# to the script's defaults so the coupling is visible here.
# Must track the Z2M container: MQTT_HOST/MQTT_PORT the broker it
# connects to, BASE_TOPIC its mqtt.base_topic. Set explicitly
# rather than left to the script's defaults so the coupling is
# visible here. Logs in with the pod's certificate (/mqtt-tls).
- name: MQTT_HOST
value: mosquitto
- name: MQTT_USER
value: zigbee2mqtt
- name: MQTT_PORT
value: "8884"
- name: MQTT_TLS_DIR
value: /mqtt-tls
- name: BASE_TOPIC
value: zigbee2mqtt
- name: STATEDIR
@@ -261,6 +283,9 @@ spec:
- name: interview-watch-script
mountPath: /script
readOnly: true
- name: mqtt-tls
mountPath: /mqtt-tls
readOnly: true
# Cooldown stamps. An explicit emptyDir rather than the image's
# /tmp, so it stays writable as non-root without depending on the
# container filesystem.
@@ -292,19 +317,16 @@ spec:
imagePullPolicy: IfNotPresent
command: [sh, /script/guard.sh]
env:
# Reuses the Z2M broker credential: its ACL is `readwrite
# zigbee2mqtt/#`, which covers reading bridge/state/bridge/groups and
# writing bridge/request/restart. No new broker user needed.
- name: MQTT_PASSWORD
valueFrom:
secretKeyRef:
name: mosquitto-zigbee2mqtt-credentials
key: password
# Must track zigbee2mqtt-config.yaml, same as interview-watch.
# Shares the Z2M certificate: its ACL is `readwrite zigbee2mqtt/#`,
# which covers reading bridge/state/bridge/groups and writing
# bridge/request/restart. Must track the Z2M container, same as
# interview-watch.
- name: MQTT_HOST
value: mosquitto
- name: MQTT_USER
value: zigbee2mqtt
- name: MQTT_PORT
value: "8884"
- name: MQTT_TLS_DIR
value: /mqtt-tls
- name: BASE_TOPIC
value: zigbee2mqtt
- name: STATEDIR
@@ -320,6 +342,9 @@ spec:
- name: discovery-guard-script
mountPath: /script
readOnly: true
- name: mqtt-tls
mountPath: /mqtt-tls
readOnly: true
# Restart cooldown stamp. Its own emptyDir rather than the image's
# /tmp, so it stays writable as non-root.
- name: discovery-guard-state
@@ -337,12 +362,24 @@ spec:
- name: config-template
configMap:
name: zigbee2mqtt-config
- name: external-converters
configMap:
name: zigbee2mqtt-external-converters
- name: coordinator-backup
secret:
secretName: zigbee2mqtt-coordinator-backup
- name: interview-watch-script
configMap:
name: zigbee2mqtt-interview-watch-script
# Client certificate of the register account zigbee2mqtt-bridge,
# issued by mqtt-account-controller. Not subPath, so a cert-manager
# renewal reaches the files in place; Z2M reads them at connect, the
# sidecars on every call. 0444 because the sidecars run as UID 1883
# and Z2M as root; only this pod mounts it.
- name: mqtt-tls
secret:
secretName: mqtt-zigbee2mqtt-bridge-tls
defaultMode: 0444
- name: interview-watch-state
emptyDir:
medium: Memory
@@ -61,16 +61,19 @@
# herdsman-only restart. discover() republishes only configs that are missing or
# whose payload changed, which after a wipe is all of them.
#
# Credentials: reuses the existing zigbee2mqtt broker user, whose ACL is
# Credentials: the pod's client certificate (register account
# zigbee2mqtt-bridge, REN-953) on the mTLS listener :8884. Its ACL is
# `readwrite zigbee2mqtt/#` — enough to read bridge/state and bridge/groups and
# to write bridge/request/restart. No new broker user, and no read grant on
# homeassistant/# (checking for the discovery configs directly would have needed
# one, which the ACL denies on purpose).
# to write bridge/request/restart. No read grant on homeassistant/# (checking
# for the discovery configs directly would have needed one, which the ACL
# denies on purpose).
set -eu
MQTT_HOST="${MQTT_HOST:-mosquitto}"
MQTT_PORT="${MQTT_PORT:-1883}"
MQTT_USER="${MQTT_USER:-zigbee2mqtt}"
MQTT_PORT="${MQTT_PORT:-8884}"
# ca.crt, tls.crt, tls.key of the client certificate. The broker takes the
# username from the certificate CN.
MQTT_TLS_DIR="${MQTT_TLS_DIR:-/mqtt-tls}"
BASE_TOPIC="${BASE_TOPIC:-zigbee2mqtt}"
# Poll cadence. Worst-case time-to-repair is CHECK_INTERVAL + CONFIRM_DELAY.
CHECK_INTERVAL="${CHECK_INTERVAL:-300}"
@@ -105,7 +108,7 @@ log() { echo "[$(date -u '+%Y-%m-%dT%H:%M:%SZ')] discovery-guard: $*"; }
# ever paid when the topic is genuinely empty.
retained() {
timeout "$((READ_TIMEOUT + 5))" mosquitto_sub -h "$MQTT_HOST" -p "$MQTT_PORT" \
-u "$MQTT_USER" -P "$MQTT_PASSWORD" \
--cafile "$MQTT_TLS_DIR/ca.crt" --cert "$MQTT_TLS_DIR/tls.crt" --key "$MQTT_TLS_DIR/tls.key" \
-t "$1" -C 1 -W "$READ_TIMEOUT" 2>/dev/null || true
}
@@ -152,7 +155,7 @@ while true; do
log "confirmed — requesting a Zigbee2MQTT restart to re-run discovery"
if timeout "$PUB_TIMEOUT" mosquitto_pub -h "$MQTT_HOST" -p "$MQTT_PORT" \
-u "$MQTT_USER" -P "$MQTT_PASSWORD" \
--cafile "$MQTT_TLS_DIR/ca.crt" --cert "$MQTT_TLS_DIR/tls.crt" --key "$MQTT_TLS_DIR/tls.key" \
-t "$BASE_TOPIC/bridge/request/restart" -m '' 2>/dev/null; then
date -u +%s > "$STAMP"
log "restart requested"
@@ -53,7 +53,10 @@ set -u
DATA=/app/data
DB="$DATA/database.db"
MQTT_HOST=${MQTT_HOST:-mosquitto}
MQTT_USER=${MQTT_USER:-zigbee2mqtt}
MQTT_PORT=${MQTT_PORT:-8884}
# ca.crt, tls.crt, tls.key of the pod's client certificate (register account
# zigbee2mqtt-bridge, REN-953). The broker takes the username from its CN.
MQTT_TLS_DIR=${MQTT_TLS_DIR:-/mqtt-tls}
# Must track mqtt.base_topic in zigbee2mqtt-config.yaml. Overridable via env so
# the two can be kept in step from the Deployment rather than by editing this
# script; the MQTT ACL for this user is scoped to `zigbee2mqtt/#`, so a change
@@ -219,10 +222,6 @@ while :; do
fi
log "frame from $ieee (nwk=$nwk cluster=$cluster) while awake -> requesting interview"
# NOTE: mosquitto_pub can only take a password via argv (-P, or an -L URL);
# it has no --pw-file or env option, so this cannot be avoided with this
# client. Not a cross-container exposure: the pod does not set
# shareProcessNamespace, so /proc is not shared with the Z2M container.
# Bounded with `timeout`, which also covers a TCP connect that hangs rather
# than being refused. The read loop is single-threaded, so an unbounded
# publish would stall it and miss other devices' wake windows.
@@ -230,7 +229,8 @@ while :; do
# NOT `mosquitto_pub -W`: that flag does not exist for mosquitto_pub (it is
# a mosquitto_sub option), and passing it makes every publish fail on a
# usage error — verified against the client in this image.
if timeout "$PUB_TIMEOUT" mosquitto_pub -h "$MQTT_HOST" -u "$MQTT_USER" -P "$MQTT_PASSWORD" \
if timeout "$PUB_TIMEOUT" mosquitto_pub -h "$MQTT_HOST" -p "$MQTT_PORT" \
--cafile "$MQTT_TLS_DIR/ca.crt" --cert "$MQTT_TLS_DIR/tls.crt" --key "$MQTT_TLS_DIR/tls.key" \
-t "$BASE_TOPIC/bridge/request/device/interview" \
-m "{\"id\":\"$ieee\"}" 2>/dev/null; then
# Stamp only on a SUCCESSFUL publish. Stamping unconditionally would burn
@@ -0,0 +1,48 @@
// Wetterstation (WS90) = the built-in zigbee-herdsman-converters definition
// plus one extra configure step that applies the reporting configuration from
// zigbee2mqtt-ws90-reporting.md. Z2M runs configure after every interview and
// on bridge/request/device/configure, so those no longer revert the device to
// the converter defaults (as happened 2026-09-24..28).
//
// The extra step runs after the built-in ones (extend order), so its values
// win. `version` makes Z2M reconfigure once when this file is first loaded:
// it re-runs configure when definition.version differs from the device's
// meta.configured. Bump it whenever REPORTING changes.
const {definitions} = require("zigbee-herdsman-converters/devices/shelly");
const base = definitions.find((d) => d.model === "WS90");
if (!base) throw new Error("WS90 definition not found in zigbee-herdsman-converters/devices/shelly");
const SHELLY = 5264;
// [cluster, attribute, reportable_change, manufacturerCode]
const REPORTING = [
["msTemperatureMeasurement", "measuredValue", 10],
["msRelativeHumidity", "measuredValue", 50],
["msPressureMeasurement", "measuredValue", 1],
["msIlluminanceMeasurement", "measuredValue", 5],
["shellyWS90Wind", "windSpeed", 1, SHELLY],
["shellyWS90Wind", "windDirection", 1, SHELLY],
["shellyWS90Wind", "gustSpeed", 1, SHELLY],
["shellyWS90UV", "uvIndex", 1, SHELLY],
["shellyWS90Rain", "rainStatus", 1, SHELLY],
["shellyWS90Rain", "precipitation", 1, SHELLY],
];
const reporting = {
isModernExtend: true,
configure: [
async (device) => {
const endpoint = device.getEndpoint(1);
for (const [cluster, attribute, change, manufacturerCode] of REPORTING) {
await endpoint.configureReporting(
cluster,
[{attribute, minimumReportInterval: 5, maximumReportInterval: 3600, reportableChange: change}],
manufacturerCode ? {manufacturerCode} : {},
);
}
},
],
};
module.exports = {...base, version: "ws90-reporting-1", extend: [...base.extend, reporting]};
@@ -2,10 +2,15 @@
Records the ZCL attribute-reporting configuration applied to the Wetterstation
(Ecowitt WS90 powered by Shelly, IEEE `0xc02cedfffe958f40`) and how to restore
it, because **this configuration lives on the device and in Z2M's
`database.db`, not in git**. Zigbee2MQTT has no settings-schema field for
reporting configuration, so there is nothing declarative to reconcile — Flux
cannot restore it and a fresh PVC will not have it.
it. The configuration itself lives on the device and in Z2M's `database.db`.
**Since 2026-10-01 it is applied from git:** the external converter
`zigbee2mqtt-ws90-converter.js` extends the built-in WS90 definition with a
configure step that sets the values below, so every interview and every
`bridge/request/device/configure` applies them instead of the converter
defaults. The manual commands under "Re-applying" are only needed if the
converter is not loaded. Keep the table and `REPORTING` in the converter in
sync, and bump the converter's `version` when they change.
## Applied configuration
@@ -71,14 +76,16 @@ the modernExtend value is the outlier.
## When this is lost
Anything that makes Z2M re-run `configure` on the device overwrites all of it
with the converter defaults:
Without the external converter, anything that makes Z2M re-run `configure` on
the device overwrites all of it with the converter defaults:
- re-pairing or re-joining the device
- re-pairing, re-joining or re-interviewing the device
- an explicit `zigbee2mqtt/bridge/request/device/configure`
- a converter update that changes the definition and triggers reconfiguration
It also will not exist on a fresh PVC. Re-apply with the commands below.
With the converter loaded, those same events apply the values above. Check
that it is loaded: Z2M logs `Successfully configured 'Wetterstation'
(definition vws90-reporting-1)` after a configure.
## Re-applying
@@ -96,25 +103,25 @@ POD=$(kubectl get pod -n home-assistant -l app.kubernetes.io/name=zigbee2mqtt -o
```
```sh
kubectl exec -n home-assistant "$POD" -c discovery-guard -- sh -c 'mosquitto_pub -h "$MQTT_HOST" -p 1883 -u "$MQTT_USER" -P "$MQTT_PASSWORD" -t "$BASE_TOPIC/bridge/request/device/configure_reporting" -m "{\"id\":\"0xc02cedfffe958f40\",\"endpoint\":1,\"cluster\":\"msTemperatureMeasurement\",\"attribute\":\"measuredValue\",\"minimum_report_interval\":5,\"maximum_report_interval\":3600,\"reportable_change\":10}"'
kubectl exec -n home-assistant "$POD" -c discovery-guard -- sh -c 'mosquitto_pub -h "$MQTT_HOST" -p "$MQTT_PORT" --cafile "$MQTT_TLS_DIR/ca.crt" --cert "$MQTT_TLS_DIR/tls.crt" --key "$MQTT_TLS_DIR/tls.key" -t "$BASE_TOPIC/bridge/request/device/configure_reporting" -m "{\"id\":\"0xc02cedfffe958f40\",\"endpoint\":1,\"cluster\":\"msTemperatureMeasurement\",\"attribute\":\"measuredValue\",\"minimum_report_interval\":5,\"maximum_report_interval\":3600,\"reportable_change\":10}"'
kubectl exec -n home-assistant "$POD" -c discovery-guard -- sh -c 'mosquitto_pub -h "$MQTT_HOST" -p 1883 -u "$MQTT_USER" -P "$MQTT_PASSWORD" -t "$BASE_TOPIC/bridge/request/device/configure_reporting" -m "{\"id\":\"0xc02cedfffe958f40\",\"endpoint\":1,\"cluster\":\"msRelativeHumidity\",\"attribute\":\"measuredValue\",\"minimum_report_interval\":5,\"maximum_report_interval\":3600,\"reportable_change\":50}"'
kubectl exec -n home-assistant "$POD" -c discovery-guard -- sh -c 'mosquitto_pub -h "$MQTT_HOST" -p "$MQTT_PORT" --cafile "$MQTT_TLS_DIR/ca.crt" --cert "$MQTT_TLS_DIR/tls.crt" --key "$MQTT_TLS_DIR/tls.key" -t "$BASE_TOPIC/bridge/request/device/configure_reporting" -m "{\"id\":\"0xc02cedfffe958f40\",\"endpoint\":1,\"cluster\":\"msRelativeHumidity\",\"attribute\":\"measuredValue\",\"minimum_report_interval\":5,\"maximum_report_interval\":3600,\"reportable_change\":50}"'
kubectl exec -n home-assistant "$POD" -c discovery-guard -- sh -c 'mosquitto_pub -h "$MQTT_HOST" -p 1883 -u "$MQTT_USER" -P "$MQTT_PASSWORD" -t "$BASE_TOPIC/bridge/request/device/configure_reporting" -m "{\"id\":\"0xc02cedfffe958f40\",\"endpoint\":1,\"cluster\":\"msPressureMeasurement\",\"attribute\":\"measuredValue\",\"minimum_report_interval\":5,\"maximum_report_interval\":3600,\"reportable_change\":1}"'
kubectl exec -n home-assistant "$POD" -c discovery-guard -- sh -c 'mosquitto_pub -h "$MQTT_HOST" -p "$MQTT_PORT" --cafile "$MQTT_TLS_DIR/ca.crt" --cert "$MQTT_TLS_DIR/tls.crt" --key "$MQTT_TLS_DIR/tls.key" -t "$BASE_TOPIC/bridge/request/device/configure_reporting" -m "{\"id\":\"0xc02cedfffe958f40\",\"endpoint\":1,\"cluster\":\"msPressureMeasurement\",\"attribute\":\"measuredValue\",\"minimum_report_interval\":5,\"maximum_report_interval\":3600,\"reportable_change\":1}"'
kubectl exec -n home-assistant "$POD" -c discovery-guard -- sh -c 'mosquitto_pub -h "$MQTT_HOST" -p 1883 -u "$MQTT_USER" -P "$MQTT_PASSWORD" -t "$BASE_TOPIC/bridge/request/device/configure_reporting" -m "{\"id\":\"0xc02cedfffe958f40\",\"endpoint\":1,\"cluster\":\"msIlluminanceMeasurement\",\"attribute\":\"measuredValue\",\"minimum_report_interval\":5,\"maximum_report_interval\":3600,\"reportable_change\":5}"'
kubectl exec -n home-assistant "$POD" -c discovery-guard -- sh -c 'mosquitto_pub -h "$MQTT_HOST" -p "$MQTT_PORT" --cafile "$MQTT_TLS_DIR/ca.crt" --cert "$MQTT_TLS_DIR/tls.crt" --key "$MQTT_TLS_DIR/tls.key" -t "$BASE_TOPIC/bridge/request/device/configure_reporting" -m "{\"id\":\"0xc02cedfffe958f40\",\"endpoint\":1,\"cluster\":\"msIlluminanceMeasurement\",\"attribute\":\"measuredValue\",\"minimum_report_interval\":5,\"maximum_report_interval\":3600,\"reportable_change\":5}"'
kubectl exec -n home-assistant "$POD" -c discovery-guard -- sh -c 'mosquitto_pub -h "$MQTT_HOST" -p 1883 -u "$MQTT_USER" -P "$MQTT_PASSWORD" -t "$BASE_TOPIC/bridge/request/device/configure_reporting" -m "{\"id\":\"0xc02cedfffe958f40\",\"endpoint\":1,\"cluster\":\"shellyWS90Wind\",\"attribute\":\"windSpeed\",\"minimum_report_interval\":5,\"maximum_report_interval\":3600,\"reportable_change\":1,\"options\":{\"manufacturerCode\":5264}}"'
kubectl exec -n home-assistant "$POD" -c discovery-guard -- sh -c 'mosquitto_pub -h "$MQTT_HOST" -p "$MQTT_PORT" --cafile "$MQTT_TLS_DIR/ca.crt" --cert "$MQTT_TLS_DIR/tls.crt" --key "$MQTT_TLS_DIR/tls.key" -t "$BASE_TOPIC/bridge/request/device/configure_reporting" -m "{\"id\":\"0xc02cedfffe958f40\",\"endpoint\":1,\"cluster\":\"shellyWS90Wind\",\"attribute\":\"windSpeed\",\"minimum_report_interval\":5,\"maximum_report_interval\":3600,\"reportable_change\":1,\"options\":{\"manufacturerCode\":5264}}"'
kubectl exec -n home-assistant "$POD" -c discovery-guard -- sh -c 'mosquitto_pub -h "$MQTT_HOST" -p 1883 -u "$MQTT_USER" -P "$MQTT_PASSWORD" -t "$BASE_TOPIC/bridge/request/device/configure_reporting" -m "{\"id\":\"0xc02cedfffe958f40\",\"endpoint\":1,\"cluster\":\"shellyWS90Wind\",\"attribute\":\"windDirection\",\"minimum_report_interval\":5,\"maximum_report_interval\":3600,\"reportable_change\":1,\"options\":{\"manufacturerCode\":5264}}"'
kubectl exec -n home-assistant "$POD" -c discovery-guard -- sh -c 'mosquitto_pub -h "$MQTT_HOST" -p "$MQTT_PORT" --cafile "$MQTT_TLS_DIR/ca.crt" --cert "$MQTT_TLS_DIR/tls.crt" --key "$MQTT_TLS_DIR/tls.key" -t "$BASE_TOPIC/bridge/request/device/configure_reporting" -m "{\"id\":\"0xc02cedfffe958f40\",\"endpoint\":1,\"cluster\":\"shellyWS90Wind\",\"attribute\":\"windDirection\",\"minimum_report_interval\":5,\"maximum_report_interval\":3600,\"reportable_change\":1,\"options\":{\"manufacturerCode\":5264}}"'
kubectl exec -n home-assistant "$POD" -c discovery-guard -- sh -c 'mosquitto_pub -h "$MQTT_HOST" -p 1883 -u "$MQTT_USER" -P "$MQTT_PASSWORD" -t "$BASE_TOPIC/bridge/request/device/configure_reporting" -m "{\"id\":\"0xc02cedfffe958f40\",\"endpoint\":1,\"cluster\":\"shellyWS90Wind\",\"attribute\":\"gustSpeed\",\"minimum_report_interval\":5,\"maximum_report_interval\":3600,\"reportable_change\":1,\"options\":{\"manufacturerCode\":5264}}"'
kubectl exec -n home-assistant "$POD" -c discovery-guard -- sh -c 'mosquitto_pub -h "$MQTT_HOST" -p "$MQTT_PORT" --cafile "$MQTT_TLS_DIR/ca.crt" --cert "$MQTT_TLS_DIR/tls.crt" --key "$MQTT_TLS_DIR/tls.key" -t "$BASE_TOPIC/bridge/request/device/configure_reporting" -m "{\"id\":\"0xc02cedfffe958f40\",\"endpoint\":1,\"cluster\":\"shellyWS90Wind\",\"attribute\":\"gustSpeed\",\"minimum_report_interval\":5,\"maximum_report_interval\":3600,\"reportable_change\":1,\"options\":{\"manufacturerCode\":5264}}"'
kubectl exec -n home-assistant "$POD" -c discovery-guard -- sh -c 'mosquitto_pub -h "$MQTT_HOST" -p 1883 -u "$MQTT_USER" -P "$MQTT_PASSWORD" -t "$BASE_TOPIC/bridge/request/device/configure_reporting" -m "{\"id\":\"0xc02cedfffe958f40\",\"endpoint\":1,\"cluster\":\"shellyWS90UV\",\"attribute\":\"uvIndex\",\"minimum_report_interval\":5,\"maximum_report_interval\":3600,\"reportable_change\":1,\"options\":{\"manufacturerCode\":5264}}"'
kubectl exec -n home-assistant "$POD" -c discovery-guard -- sh -c 'mosquitto_pub -h "$MQTT_HOST" -p "$MQTT_PORT" --cafile "$MQTT_TLS_DIR/ca.crt" --cert "$MQTT_TLS_DIR/tls.crt" --key "$MQTT_TLS_DIR/tls.key" -t "$BASE_TOPIC/bridge/request/device/configure_reporting" -m "{\"id\":\"0xc02cedfffe958f40\",\"endpoint\":1,\"cluster\":\"shellyWS90UV\",\"attribute\":\"uvIndex\",\"minimum_report_interval\":5,\"maximum_report_interval\":3600,\"reportable_change\":1,\"options\":{\"manufacturerCode\":5264}}"'
kubectl exec -n home-assistant "$POD" -c discovery-guard -- sh -c 'mosquitto_pub -h "$MQTT_HOST" -p 1883 -u "$MQTT_USER" -P "$MQTT_PASSWORD" -t "$BASE_TOPIC/bridge/request/device/configure_reporting" -m "{\"id\":\"0xc02cedfffe958f40\",\"endpoint\":1,\"cluster\":\"shellyWS90Rain\",\"attribute\":\"rainStatus\",\"minimum_report_interval\":5,\"maximum_report_interval\":3600,\"reportable_change\":1,\"options\":{\"manufacturerCode\":5264}}"'
kubectl exec -n home-assistant "$POD" -c discovery-guard -- sh -c 'mosquitto_pub -h "$MQTT_HOST" -p "$MQTT_PORT" --cafile "$MQTT_TLS_DIR/ca.crt" --cert "$MQTT_TLS_DIR/tls.crt" --key "$MQTT_TLS_DIR/tls.key" -t "$BASE_TOPIC/bridge/request/device/configure_reporting" -m "{\"id\":\"0xc02cedfffe958f40\",\"endpoint\":1,\"cluster\":\"shellyWS90Rain\",\"attribute\":\"rainStatus\",\"minimum_report_interval\":5,\"maximum_report_interval\":3600,\"reportable_change\":1,\"options\":{\"manufacturerCode\":5264}}"'
kubectl exec -n home-assistant "$POD" -c discovery-guard -- sh -c 'mosquitto_pub -h "$MQTT_HOST" -p 1883 -u "$MQTT_USER" -P "$MQTT_PASSWORD" -t "$BASE_TOPIC/bridge/request/device/configure_reporting" -m "{\"id\":\"0xc02cedfffe958f40\",\"endpoint\":1,\"cluster\":\"shellyWS90Rain\",\"attribute\":\"precipitation\",\"minimum_report_interval\":5,\"maximum_report_interval\":3600,\"reportable_change\":1,\"options\":{\"manufacturerCode\":5264}}"'
kubectl exec -n home-assistant "$POD" -c discovery-guard -- sh -c 'mosquitto_pub -h "$MQTT_HOST" -p "$MQTT_PORT" --cafile "$MQTT_TLS_DIR/ca.crt" --cert "$MQTT_TLS_DIR/tls.crt" --key "$MQTT_TLS_DIR/tls.key" -t "$BASE_TOPIC/bridge/request/device/configure_reporting" -m "{\"id\":\"0xc02cedfffe958f40\",\"endpoint\":1,\"cluster\":\"shellyWS90Rain\",\"attribute\":\"precipitation\",\"minimum_report_interval\":5,\"maximum_report_interval\":3600,\"reportable_change\":1,\"options\":{\"manufacturerCode\":5264}}"'
```
These are idempotent — re-sending a request that matches the current
+19 -8
View File
@@ -24,7 +24,7 @@ spec:
# unchanged, so Kubernetes has no reason to replace anything, and
# this image is deliberately NOT enrolled in Flux image automation
# — see kubernetes/infrastructure/image-automation/README.md, which
# lists ghcr.io/konairius/ical-proxy as having "only main, latest,
# lists gitea.renner.uno/konairius/ical-proxy as having "only main, latest,
# and main-<sha> commit builds; no release tags", so there is no
# ImagePolicy watching it. The pods therefore sat on a 21-day-old
# image while :latest moved underneath them, and the only way to
@@ -35,15 +35,26 @@ spec:
# what is RUNNING recoverable from this repo rather than "whatever
# :latest meant the last time a pod happened to restart".
#
# main-99a912b is the merge of konairius/ical-proxy#12, which adds
# the summary_match/summary_replace parameters this deployment
# needs to strip "| Abfuhrkalender - Landkreis Amberg-Sulzbach"
# from every waste collection.
# The image comes from the Gitea package registry, built by
# Woodpecker (.woodpecker.yml in konairius/ical-proxy) on every
# push to main. It is amd64-only and pulls without credentials, so
# no imagePullSecret. main-4783abe adds two hardening changes on
# top of main-db90a59: an SSRF guard (upstreams and redirect hops
# resolving to private/loopback/link-local addresses are refused;
# public redirects are still followed, up to 5) and a cap of 20
# concurrent /proxy upstream fetches (over the cap: 429 +
# Retry-After). main-73b5d97 then raises the server WriteTimeout
# from 10s to 40s (the 30s upstream fetch timeout + 10s headroom),
# so a slow-but-legitimate upstream is no longer cut off before
# /proxy can answer. main-926ead0 caps the upstream response body
# at 2 MiB (larger feeds get 413 instead of being buffered whole,
# REN-230) and logs upstream fetch failures with the host,
# answering 502 instead of 500. The summary_match/summary_replace
# parameters this deployment needs are unchanged.
#
# Bumping this is a manual, reviewed edit. The tag format is
# main-<short-sha> (docker/metadata-action type=sha with the branch
# as prefix).
image: ghcr.io/konairius/ical-proxy:main-99a912b
# main-<short-sha>, the first 7 characters of the main commit.
image: gitea.renner.uno/konairius/ical-proxy:main-926ead0
ports:
- containerPort: 8080
name: http
+1 -1
View File
@@ -32,7 +32,7 @@ spec:
type: RuntimeDefault
containers:
- name: immich-machine-learning
image: ghcr.io/immich-app/immich-machine-learning:v3.2.2 # {"$imagepolicy": "flux-system:immich-machine-learning"}
image: ghcr.io/immich-app/immich-machine-learning:v3.2.4 # {"$imagepolicy": "flux-system:immich-machine-learning"}
ports:
- name: http
containerPort: 3003
+3 -18
View File
@@ -8,26 +8,11 @@
# back into `kubernetes/apps/immich/` at retirement is the cleanup.
#
# Sizing:
# - library: 300Gi — LXC 225's /mnt/media/immich is currently ~250 GiB.
# StorageClass ceph-filesystem has allowVolumeExpansion=true; grow with
# `kubectl patch pvc immich-library -p '{"spec":{"resources":{"requests":{"storage":"<new>"}}}}'`.
# - library-bulk: 300Gi — the media library is ~250 GiB.
# StorageClass ceph-filesystem-bulk has allowVolumeExpansion=true; grow with
# `kubectl patch pvc immich-library-bulk -p '{"spec":{"resources":{"requests":{"storage":"<new>"}}}}'`.
# - ml-cache: 20Gi — face-recognition + CLIP model cache. Survives pod
# restarts so ML doesn't re-download on every rollout.
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: immich-library
namespace: immich
annotations:
kustomize.toolkit.fluxcd.io/prune: disabled
spec:
accessModes:
- ReadWriteMany
storageClassName: ceph-filesystem
resources:
requests:
storage: 300Gi
---
# Media root on the EC 2+1 bulk pool; thumbs mount separately below.
apiVersion: v1
kind: PersistentVolumeClaim
+2 -2
View File
@@ -66,7 +66,7 @@ spec:
# The library PVC is populated by the seed phase before this
# Deployment reconciles, so no rsync init is needed here.
- name: fetch-le-staging-roots
image: curlimages/curl:8.10.1
image: curlimages/curl:8.22.0@sha256:58adaa4e8dca9c988bae2aba4ab3434a0bb2da16bbe3f92dec39ec7785166777
command:
- sh
- -c
@@ -87,7 +87,7 @@ spec:
mountPath: /ca
containers:
- name: immich-server
image: ghcr.io/immich-app/immich-server:v3.2.2 # {"$imagepolicy": "flux-system:immich-server"}
image: ghcr.io/immich-app/immich-server:v3.2.4 # {"$imagepolicy": "flux-system:immich-server"}
ports:
- name: http
containerPort: 3001
@@ -57,7 +57,7 @@ spec:
runAsNonRoot: false
initContainers:
- name: wait-for-influxd
image: influxdb:2.7.4
image: influxdb:2.9.1@sha256:db0bdab1e5ad5ee899c127b8c13d9c986a3ced78cd9200dd80a1064bf1533b6e
env:
- { name: INFLUX_HOST, value: http://influxdb-influxdb2.influxdb.svc.cluster.local:8086 }
- { name: INFLUX_ORG, value: renner }
@@ -80,7 +80,7 @@ spec:
echo "[$(date -u +%H:%M:%S)] $INFLUX_HOST ready and authenticated"
containers:
- name: create
image: influxdb:2.7.4
image: influxdb:2.9.1@sha256:db0bdab1e5ad5ee899c127b8c13d9c986a3ced78cd9200dd80a1064bf1533b6e
env:
- { name: INFLUX_HOST, value: http://influxdb-influxdb2.influxdb.svc.cluster.local:8086 }
- { name: INFLUX_ORG, value: renner }
+3 -3
View File
@@ -88,7 +88,7 @@ spec:
# state). Two-stage so we don't try to create an auth before
# the chart's `influx setup` has finished.
- name: wait-for-influxd
image: influxdb:2.7.4
image: influxdb:2.9.1@sha256:db0bdab1e5ad5ee899c127b8c13d9c986a3ced78cd9200dd80a1064bf1533b6e
env:
- { name: INFLUX_HOST, value: http://influxdb-influxdb2.influxdb.svc.cluster.local:8086 }
- { name: INFLUX_ORG, value: renner }
@@ -111,7 +111,7 @@ spec:
echo "[$(date -u +%H:%M:%S)] $INFLUX_HOST ready and authenticated"
containers:
- name: create
image: influxdb:2.7.4
image: influxdb:2.9.1@sha256:db0bdab1e5ad5ee899c127b8c13d9c986a3ced78cd9200dd80a1064bf1533b6e
env:
- { name: INFLUX_HOST, value: http://influxdb-influxdb2.influxdb.svc.cluster.local:8086 }
- { name: INFLUX_ORG, value: renner }
@@ -133,7 +133,7 @@ spec:
set -euo pipefail
log() { printf '[%s] %s\n' "$(date -u +%H:%M:%S)" "$*"; }
# Need jq + kubectl. influxdb:2.7.4 has neither baked in.
# Need jq + kubectl. The influxdb image has neither baked in.
apt-get update -qq
apt-get install -y --no-install-recommends curl jq ca-certificates >/dev/null
KV=$(curl -fsSL https://dl.k8s.io/release/stable.txt)
+9 -2
View File
@@ -53,8 +53,9 @@ spec:
values:
image:
repository: influxdb
# Match VM 108 for format compatibility with `influx restore`.
tag: "2.7.4"
# Was pinned to VM 108's 2.7.4 for the one-time `influx restore`; that
# migration is done. No downgrade below 2.9 without `influxd downgrade`.
tag: "2.9.1@sha256:db0bdab1e5ad5ee899c127b8c13d9c986a3ced78cd9200dd80a1064bf1533b6e"
# Single replica — InfluxDB OSS doesn't cluster. RWO Ceph-block + Velero
# backups (pending) is the durability story.
persistence:
@@ -93,6 +94,12 @@ spec:
env:
- name: INFLUXD_STORAGE_WRITE_TIMEOUT
value: "60s"
# 2.9 hashes API tokens on startup by default. Hashed tokens cannot be
# read back, so the token Jobs' `influx auth list` reuse would break,
# and a downgrade below 2.8 would erase every token (HA, Grafana).
# Keep tokens unhashed; enable hashing later as its own change.
- name: INFLUXD_USE_HASHED_TOKENS
value: "false"
# The chart defaults to liveness/readiness with initialDelaySeconds=0,
# so after a crash restart the kubelet kills the pod before shards
# finish opening. Give it 10 minutes to come up cleanly.
@@ -5,3 +5,4 @@ resources:
- helmrelease.yaml
- ha-token-job.yaml
- grafana-token-job.yaml
- volumesnapshot-pre-2.9.yaml
@@ -0,0 +1,18 @@
---
# Point-in-time copy of the InfluxDB data PVC, taken before the 2.7.4 -> 2.9.1
# upgrade (homelab #1130, REN-723). Merge this first and check readyToUse=true
# before #1130: 2.9 migrates the metadata store, so the way back is
# `influxd downgrade 2.4` or a restore from this snapshot.
#
# Crash-consistent (taken from the live RBD volume), like the velero CSI
# snapshots. Delete this file once 2.9 has run cleanly; the snapshot goes
# with it (prune).
apiVersion: snapshot.storage.k8s.io/v1
kind: VolumeSnapshot
metadata:
name: influxdb-influxdb2-pre-2-9
namespace: influxdb
spec:
volumeSnapshotClassName: ceph-block-snapclass
source:
persistentVolumeClaimName: influxdb-influxdb2
+2 -2
View File
@@ -48,7 +48,7 @@ spec:
# this sentinel: the entrypoint copies AccountsSettings.json
# into ephemeral /config-internal rather than symlinking it.
- name: seed-config
image: busybox:1.37.0
image: busybox:1.38.0@sha256:fd7dc98638c8e305f4dc34e979f1c0fdfdcaeb0fbf8fcff77ae834b6da3d7e6e
command: ["/bin/sh", "-eu", "-c"]
args:
- |
@@ -94,7 +94,7 @@ spec:
- name: libation
# Pinned by digest: Spegel caches mutable tag resolutions, so
# :latest stayed on 13.7.11 despite imagePullPolicy Always.
image: docker.io/rmcrackan/libation:14.2.1@sha256:6f9d8ba19dc3803dd6ba295ab5a7abfb6ff3bc06286eebf4ecd8ccbe43245888
image: docker.io/rmcrackan/libation:14.2.2@sha256:fe188ac3c4ce63cc305971c76e648748341427e16bcf884011da8a384fd3908c
# The entrypoint stages config into ephemeral /config-internal
# by copy (only the DB is symlinked to the PVC), so Audible
# tokens refreshed during a run are lost at container exit.
+1 -1
View File
@@ -54,7 +54,7 @@ spec:
type: RuntimeDefault
containers:
- name: llama-server
image: ghcr.io/ggml-org/llama.cpp:server-vulkan-b10731
image: ghcr.io/ggml-org/llama.cpp:server-vulkan-b10731@sha256:0262343f64f030e8efff15ec05ee8180b69b7f6745de2caa3af5148e0dcb8aba
args:
# The one place this model is named; llama-server resolves the repo
# and downloads it itself, so there is nothing to keep in sync.
+1 -1
View File
@@ -43,7 +43,7 @@ spec:
type: RuntimeDefault
containers:
- name: llama-embed
image: ghcr.io/ggml-org/llama.cpp:server-vulkan-b10731
image: ghcr.io/ggml-org/llama.cpp:server-vulkan-b10731@sha256:0262343f64f030e8efff15ec05ee8180b69b7f6745de2caa3af5148e0dcb8aba
args:
- --hf-repo
- gpustack/bge-m3-GGUF:Q8_0
+1 -1
View File
@@ -32,7 +32,7 @@ spec:
type: RuntimeDefault
containers:
- name: wiki-embed
image: ghcr.io/ggml-org/llama.cpp:server-vulkan-b10731
image: ghcr.io/ggml-org/llama.cpp:server-vulkan-b10731@sha256:0262343f64f030e8efff15ec05ee8180b69b7f6745de2caa3af5148e0dcb8aba
args:
- --hf-repo
- gpustack/bge-m3-GGUF:Q8_0
+222
View File
@@ -0,0 +1,222 @@
# matrix-bridge (REN-569, REN-587): Matrix appservice between Element and the
# Paperclip agents. One room per agent with the owner; owner messages become
# comments on the agent's chat card, the agent's comments come back to the
# room. Source: gitea.renner.uno/konairius/matrix-bridge.
#
# No volume: the bridge keeps its state in the bot's account data on Synapse.
# No ingress: only Synapse talks to it (appservice transactions on :8080).
#
# Secrets:
# matrix-bridge-tokens as_token (bridge -> Synapse) and hs_token (Synapse
# -> bridge), generated once in-cluster by ESO, plus
# the appservice registration Synapse loads from
# app_service_config_files (synapse.yaml). Both sides
# read the same Secret, so the tokens cannot drift.
# Deleting the Secret regenerates both; Reloader
# restarts Synapse and the bridge.
# matrix-bridge paperclip_api_key from OpenBao
# homelab/apps/matrix-bridge: the Paperclip board key
# "matrix-bridge (board)" (REN-582).
apiVersion: generators.external-secrets.io/v1alpha1
kind: Password
metadata:
name: matrix-bridge-tokens
namespace: matrix
spec:
length: 64
digits: 16
symbols: 0
allowRepeat: true
noUpper: false
secretKeys:
- as_token
- hs_token
---
apiVersion: external-secrets.io/v1
kind: ExternalSecret
metadata:
name: matrix-bridge-tokens
namespace: matrix
spec:
# Generate once; Periodic would rotate the tokens every refresh.
refreshPolicy: CreatedOnce
target:
name: matrix-bridge-tokens
template:
engineVersion: v2
data:
as_token: "{{ .as_token }}"
hs_token: "{{ .hs_token }}"
# Agent users are @agent_<urlKey>:matrix.renner.uno; the bot is
# @paperclip:matrix.renner.uno.
registration.yaml: |
id: matrix-bridge
url: http://matrix-bridge:8080
as_token: "{{ .as_token }}"
hs_token: "{{ .hs_token }}"
sender_localpart: paperclip
rate_limited: false
namespaces:
users:
- exclusive: true
regex: "@agent_.*:matrix\\.renner\\.uno"
aliases: []
rooms: []
dataFrom:
- sourceRef:
generatorRef:
apiVersion: generators.external-secrets.io/v1alpha1
kind: Password
name: matrix-bridge-tokens
---
apiVersion: external-secrets.io/v1
kind: ExternalSecret
metadata:
name: matrix-bridge
namespace: matrix
spec:
refreshInterval: 1h
secretStoreRef:
kind: ClusterSecretStore
name: openbao
target:
name: matrix-bridge
data:
- secretKey: paperclip_api_key
remoteRef:
key: apps/matrix-bridge
property: paperclip_api_key
---
apiVersion: apps/v1
kind: Deployment
metadata:
name: matrix-bridge
namespace: matrix
annotations:
secret.reloader.stakater.com/reload: matrix-bridge,matrix-bridge-tokens
labels:
app.kubernetes.io/name: matrix-bridge
app.kubernetes.io/part-of: matrix
spec:
replicas: 1
# One poller only: two pods would bridge every comment twice.
strategy:
type: Recreate
selector:
matchLabels:
app.kubernetes.io/name: matrix-bridge
template:
metadata:
labels:
app.kubernetes.io/name: matrix-bridge
app.kubernetes.io/part-of: matrix
spec:
automountServiceAccountToken: false
securityContext:
runAsNonRoot: true
# `node` in node:24-alpine.
runAsUser: 1000
runAsGroup: 1000
seccompProfile:
type: RuntimeDefault
containers:
- name: matrix-bridge
image: gitea.renner.uno/konairius/matrix-bridge:build.1791195981
securityContext:
allowPrivilegeEscalation: false
readOnlyRootFilesystem: true
capabilities:
drop: ["ALL"]
env:
- name: MATRIX_HOMESERVER_URL
value: http://synapse:8008
- name: MATRIX_SERVER_NAME
value: matrix.renner.uno
- name: MATRIX_OWNER
value: "@k.renner:matrix.renner.uno"
- name: MATRIX_AS_TOKEN
valueFrom:
secretKeyRef:
name: matrix-bridge-tokens
key: as_token
- name: MATRIX_HS_TOKEN
valueFrom:
secretKeyRef:
name: matrix-bridge-tokens
key: hs_token
- name: PAPERCLIP_API_URL
value: http://paperclip.paperclip.svc.cluster.local:3100
- name: PAPERCLIP_API_KEY
valueFrom:
secretKeyRef:
name: matrix-bridge
key: paperclip_api_key
- name: PAPERCLIP_COMPANY_ID
value: 72f7b75a-10b0-4084-ad5e-a0cdf31c7caf
- name: PAPERCLIP_PROJECT_ID
value: 67143c0b-e9a1-44c1-b012-0f8fa25625aa
# Card link in the topic of each per-card room (REN-668).
- name: PAPERCLIP_PUBLIC_URL
value: https://paperclip.renner.uno
ports:
- name: http
containerPort: 8080
resources:
requests:
cpu: 10m
memory: 64Mi
limits:
memory: 256Mi
# /health is 503 when the Paperclip comment poll fails, so it gates
# readiness only; a Paperclip outage must not restart the bridge.
readinessProbe:
httpGet:
path: /health
port: http
periodSeconds: 10
livenessProbe:
tcpSocket:
port: http
periodSeconds: 30
failureThreshold: 4
volumeMounts:
- name: tmp
mountPath: /tmp
volumes:
- name: tmp
emptyDir: {}
---
apiVersion: v1
kind: Service
metadata:
name: matrix-bridge
namespace: matrix
spec:
selector:
app.kubernetes.io/name: matrix-bridge
ports:
- name: http
port: 8080
targetPort: http
---
# The bridge calls the Paperclip API in-cluster. Synapse <-> bridge and DNS
# are covered by matrix-app-egress (part-of: matrix); the Paperclip side of
# this flow is in apps/paperclip/network-policy.yaml.
apiVersion: cilium.io/v2
kind: CiliumNetworkPolicy
metadata:
name: matrix-bridge-paperclip-egress
namespace: matrix
spec:
endpointSelector:
matchLabels:
app.kubernetes.io/name: matrix-bridge
egress:
- toEndpoints:
- matchLabels:
"k8s:io.kubernetes.pod.namespace": paperclip
app.kubernetes.io/name: paperclip
toPorts:
- ports:
- port: "3100"
protocol: TCP
+45
View File
@@ -0,0 +1,45 @@
apiVersion: postgresql.cnpg.io/v1
kind: Cluster
metadata:
name: mx-pg
namespace: matrix
spec:
instances: 2
smartShutdownTimeout: 10
stopDelay: 60
imageName: ghcr.io/cloudnative-pg/postgresql:16
enableSuperuserAccess: true
storage:
storageClass: ceph-block
size: 5Gi
plugins:
- name: barman-cloud.cloudnative-pg.io
isWALArchiver: true
parameters:
barmanObjectName: mx-pg-store
bootstrap:
initdb:
database: synapse
owner: synapse
# Synapse refuses to start on a database whose collation is not C
# (its text indexes depend on byte order). Fixed at initdb time; it
# cannot be changed on an existing database.
encoding: UTF8
localeCollate: C
localeCType: C
postgresql:
parameters:
shared_buffers: "128MB"
max_connections: "50"
# Same write-reduction set as the other CNPG clusters; rationale in
# apps/trmnl/cluster.yaml.
wal_compression: "zstd"
archive_timeout: "30min"
checkpoint_timeout: "15min"
max_wal_size: "2GB"
resources:
requests:
cpu: 100m
memory: 256Mi
limits:
memory: 512Mi
+137
View File
@@ -0,0 +1,137 @@
# Element Web at element.renner.uno, locked to matrix.renner.uno: no custom
# homeserver, no guests, no registration, no integration manager, no
# analytics (no posthog block), no bug-report endpoint.
#
# feature_login_with_qr: "Sign in with QR code" on the welcome page, so a new
# browser can be linked from a signed-in device. Linking a phone from the
# desktop (Settings → Sessions → Link new device) needs no flag; it shows
# when the server offers MSC4108 and the session has cross-signing.
apiVersion: v1
kind: ConfigMap
metadata:
name: element-config
namespace: matrix
data:
config.json: |
{
"default_server_config": {
"m.homeserver": {
"base_url": "https://matrix.renner.uno",
"server_name": "matrix.renner.uno"
}
},
"disable_custom_urls": true,
"disable_guests": true,
"disable_3pid_login": true,
"default_country_code": "DE",
"room_directory": { "servers": ["matrix.renner.uno"] },
"integrations_ui_url": "",
"integrations_rest_url": "",
"integrations_widgets_urls": [],
"bug_report_endpoint_url": "",
"show_labs_settings": false,
"features": {
"feature_login_with_qr": true
},
"setting_defaults": {
"UIFeature.registration": false,
"UIFeature.passwordReset": false,
"UIFeature.thirdPartyId": false,
"UIFeature.identityServer": false,
"UIFeature.deactivate": false
}
}
---
apiVersion: apps/v1
kind: Deployment
metadata:
name: element-web
namespace: matrix
annotations:
configmap.reloader.stakater.com/reload: element-config
labels:
app.kubernetes.io/name: element-web
app.kubernetes.io/part-of: matrix
spec:
replicas: 1
selector:
matchLabels:
app.kubernetes.io/name: element-web
template:
metadata:
labels:
app.kubernetes.io/name: element-web
app.kubernetes.io/part-of: matrix
spec:
automountServiceAccountToken: false
securityContext:
runAsNonRoot: true
runAsUser: 101
runAsGroup: 101
seccompProfile:
type: RuntimeDefault
containers:
- name: element-web
image: ghcr.io/element-hq/element-web:v1.12.30@sha256:3e7dbd4424de9e11c812bc740acf2725b2abe66ea0d0802023b56fd85d3fa09a
securityContext:
allowPrivilegeEscalation: false
readOnlyRootFilesystem: true
capabilities:
drop: ["ALL"]
env:
# Unprivileged port: the image runs as nginx, not root.
- name: ELEMENT_WEB_PORT
value: "8080"
ports:
- name: http
containerPort: 8080
resources:
requests:
cpu: 10m
memory: 32Mi
limits:
memory: 128Mi
readinessProbe:
httpGet:
path: /config.json
port: http
periodSeconds: 10
livenessProbe:
httpGet:
path: /config.json
port: http
periodSeconds: 30
volumeMounts:
# The entrypoint copies /app/config*.json to /tmp and serves it
# from there, so the ConfigMap lands at the source path.
- name: config
mountPath: /app/config.json
subPath: config.json
readOnly: true
# Writable paths for a read-only root: the entrypoint renders the
# nginx template into conf.d; pid and temp files go to /tmp.
- name: conf-d
mountPath: /etc/nginx/conf.d
- name: tmp
mountPath: /tmp
volumes:
- name: config
configMap:
name: element-config
- name: conf-d
emptyDir: {}
- name: tmp
emptyDir: {}
---
apiVersion: v1
kind: Service
metadata:
name: element-web
namespace: matrix
spec:
selector:
app.kubernetes.io/name: element-web
ports:
- name: http
port: 80
targetPort: http
@@ -0,0 +1,26 @@
# OpenBao homelab/apps/matrix (seeded by Hermes):
# owner_user localpart of the owner account (k.renner)
# owner_password the owner's password (MAS password login)
# registration_shared_secret random; Synapse's macaroon key fallback
# mas_matrix_secret random; MAS <-> Synapse shared secret
# mas_encryption 32 bytes hex; MAS encrypts tokens at rest
# mas_rsa_key, mas_ec_key PEM private keys; MAS signs its tokens
#
# The owner reads the login from OpenBao; it never appears in a comment, a
# manifest or a log. owner_password is the password the account was created
# with; changing it in OpenBao does not change the account password.
apiVersion: external-secrets.io/v1
kind: ExternalSecret
metadata:
name: synapse-secrets
namespace: matrix
spec:
refreshInterval: 1h
secretStoreRef:
kind: ClusterSecretStore
name: openbao
target:
name: synapse-secrets
dataFrom:
- extract:
key: apps/matrix
@@ -0,0 +1,15 @@
apiVersion: external-secrets.io/v1
kind: ExternalSecret
metadata:
name: hetzner-s3-creds
namespace: matrix
spec:
refreshInterval: 1h
secretStoreRef:
kind: ClusterSecretStore
name: openbao
target:
name: hetzner-s3-creds
dataFrom:
- extract:
key: infrastructure/hetzner-s3
+161
View File
@@ -0,0 +1,161 @@
# Public (REN-663): each Ingress carries dns.renner.uno/public, so
# netbird-service-sync publishes its host through the NetBird proxy
# (Cloudflare wildcard -> proxy.renner.uno -> TLS passthrough to Traefik) and
# external-dns-unifi skips it; LAN clients follow the public answer and the UDM
# hairpins back in. Same path as audiobooks/immich. Federation stays off.
#
# Synapse: only the client-facing paths. /_synapse/admin stays off the
# Ingress (in-cluster only); /_matrix/federation and /_matrix/key are not
# served by the listener anyway.
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: synapse
namespace: matrix
labels:
# Registered publicly (Cloudflare wildcard -> NetBird proxy); the UDM
# external-dns instance skips it, LAN reaches it via the hairpin NAT.
dns.renner.uno/public: "true"
annotations:
cert-manager.io/cluster-issuer: letsencrypt-cluster
spec:
ingressClassName: traefik
tls:
- hosts:
- matrix.renner.uno
secretName: matrix-tls
rules:
- host: matrix.renner.uno
http:
paths:
# Legacy login/logout/refresh go to MAS (its compat layer). Longer
# paths win in Traefik, so these override /_matrix/client below.
- path: /_matrix/client/v3/login
pathType: Prefix
backend:
service:
name: mas
port:
number: 8080
- path: /_matrix/client/v3/logout
pathType: Prefix
backend:
service:
name: mas
port:
number: 8080
- path: /_matrix/client/v3/refresh
pathType: Prefix
backend:
service:
name: mas
port:
number: 8080
- path: /_matrix/client/r0/login
pathType: Prefix
backend:
service:
name: mas
port:
number: 8080
- path: /_matrix/client/r0/logout
pathType: Prefix
backend:
service:
name: mas
port:
number: 8080
- path: /_matrix/client/r0/refresh
pathType: Prefix
backend:
service:
name: mas
port:
number: 8080
- path: /_matrix/client
pathType: Prefix
backend:
service:
name: synapse
port:
number: 8008
- path: /_matrix/media
pathType: Prefix
backend:
service:
name: synapse
port:
number: 8008
- path: /_synapse/client
pathType: Prefix
backend:
service:
name: synapse
port:
number: 8008
- path: /.well-known/matrix/client
pathType: Exact
backend:
service:
name: synapse
port:
number: 8008
---
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: element-web
namespace: matrix
labels:
# Registered publicly (Cloudflare wildcard -> NetBird proxy); the UDM
# external-dns instance skips it, LAN reaches it via the hairpin NAT.
dns.renner.uno/public: "true"
annotations:
cert-manager.io/cluster-issuer: letsencrypt-cluster
spec:
ingressClassName: traefik
tls:
- hosts:
- element.renner.uno
secretName: element-tls
rules:
- host: element.renner.uno
http:
paths:
- path: /
pathType: Prefix
backend:
service:
name: element-web
port:
number: 80
---
# MAS: login pages, OAuth endpoints and account management.
apiVersion: networking.k8s.io/v1
kind: Ingress
metadata:
name: mas
namespace: matrix
labels:
# Registered publicly (Cloudflare wildcard -> NetBird proxy); the UDM
# external-dns instance skips it, LAN reaches it via the hairpin NAT.
dns.renner.uno/public: "true"
annotations:
cert-manager.io/cluster-issuer: letsencrypt-cluster
spec:
ingressClassName: traefik
tls:
- hosts:
- account.matrix.renner.uno
secretName: mas-tls
rules:
- host: account.matrix.renner.uno
http:
paths:
- path: /
pathType: Prefix
backend:
service:
name: mas
port:
number: 8080
+15
View File
@@ -0,0 +1,15 @@
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
resources:
- externalsecret.yaml
- synapse.yaml
- mas.yaml
- element.yaml
- bridge.yaml
- ingress.yaml
# mx-pg CNPG Postgres + offsite Barman backup. The media store and signing
# key are on synapse-data, backed up by Velero (matrix-daily).
- cluster.yaml
- objectstore.yaml
- scheduled-backup.yaml
- hetzner-creds-externalsecret.yaml
+229
View File
@@ -0,0 +1,229 @@
# Matrix Authentication Service (MAS) for matrix.renner.uno (REN-567).
#
# Synapse delegates all logins to MAS (matrix_authentication_service in
# synapse.yaml). Why: Element X only signs in with a password or through
# MAS. MAS gives it a one-tap passkey login through Authentik
# (upstream_oauth2 below) and makes QR sign-in possible.
#
# Accounts: the owner account was moved from Synapse into MAS by syn2mas
# (the migrate-to-mas init container in synapse.yaml), with its password
# hash and sessions. The first Authentik login links to it by localpart
# (on_conflict: add). The Authentik application admits only the Matrix
# Users group, so no one else can create an account through it. Password
# login stays on as a fallback; self-registration and recovery are off.
#
# Secrets: OpenBao homelab/apps/matrix (synapse-secrets). The database is
# `mas` in mx-pg (Barman backup); MAS keeps no other state.
apiVersion: v1
kind: ConfigMap
metadata:
name: mas-config
namespace: matrix
data:
config.yaml: |
http:
public_base: https://account.matrix.renner.uno/
listeners:
- name: web
resources:
- name: discovery
- name: human
- name: oauth
- name: compat
- name: graphql
- name: assets
binds:
- address: "[::]:8080"
- name: internal
resources:
- name: health
binds:
- address: "[::]:8081"
# Password from the mounted mx-pg-app Secret; nothing in this file.
database:
host: mx-pg-rw
port: 5432
username: synapse
password_file: /pg/password
database: mas
matrix:
kind: synapse
homeserver: matrix.renner.uno
endpoint: http://synapse:8008/
secret_file: /secrets/mas_matrix_secret
secrets:
encryption_file: /secrets/mas_encryption
keys:
- key_file: /secrets/mas_rsa_key
- key_file: /secrets/mas_ec_key
passwords:
enabled: true
# Version 1 must be bcrypt with no pepper: syn2mas imports Synapse's
# bcrypt hashes under it. New passwords are hashed with argon2id.
schemes:
- version: 1
algorithm: bcrypt
- version: 2
algorithm: argon2id
minimum_complexity: 3
account:
password_registration_enabled: false
password_recovery_enabled: false
email_change_allowed: false
login_with_email_allowed: false
account_deactivation_allowed: false
# No mail server; MAS sends nothing.
email:
transport: blackhole
upstream_oauth2:
providers:
- id: 01M4480KWZGN9HBNB5SSNGT2M1
human_name: Authentik (passkey)
issuer: https://auth.renner.uno/application/o/matrix/
client_id: matrix-mas
# Public client + PKCE: no shared client secret to keep in sync.
token_endpoint_auth_method: none
pkce_method: always
scope: "openid profile email"
claims_imports:
# Authentik username = Matrix localpart. `add` links the first
# login to the migrated account of the same name.
localpart:
action: require
template: "{{ user.preferred_username }}"
on_conflict: add
displayname:
action: suggest
template: "{{ user.name }}"
email:
action: ignore
---
apiVersion: apps/v1
kind: Deployment
metadata:
name: mas
namespace: matrix
annotations:
configmap.reloader.stakater.com/reload: mas-config
secret.reloader.stakater.com/reload: synapse-secrets
labels:
app.kubernetes.io/name: mas
app.kubernetes.io/part-of: matrix
spec:
replicas: 1
selector:
matchLabels:
app.kubernetes.io/name: mas
template:
metadata:
labels:
app.kubernetes.io/name: mas
app.kubernetes.io/part-of: matrix
spec:
automountServiceAccountToken: false
enableServiceLinks: false
securityContext:
runAsNonRoot: true
runAsUser: 65532
runAsGroup: 65532
seccompProfile:
type: RuntimeDefault
containers:
- name: mas
image: ghcr.io/element-hq/matrix-authentication-service:1.26.0@sha256:e089f1048a1d4a9a492ed17b9fe759100f1bd619407b001f5927928d88b780c4
# The server applies database migrations and syncs the upstream
# providers from the config on start.
args: ["server", "--config", "/config/config.yaml"]
securityContext:
allowPrivilegeEscalation: false
readOnlyRootFilesystem: true
capabilities:
drop: ["ALL"]
ports:
- name: http
containerPort: 8080
- name: internal
containerPort: 8081
resources:
requests:
cpu: 20m
memory: 64Mi
limits:
memory: 256Mi
readinessProbe:
httpGet:
path: /health
port: internal
periodSeconds: 10
livenessProbe:
httpGet:
path: /health
port: internal
periodSeconds: 30
timeoutSeconds: 5
failureThreshold: 4
volumeMounts:
- name: config
mountPath: /config
readOnly: true
- name: secrets
mountPath: /secrets
readOnly: true
- name: pg
mountPath: /pg
readOnly: true
volumes:
- name: config
configMap:
name: mas-config
- name: secrets
secret:
secretName: synapse-secrets
items:
- key: mas_matrix_secret
path: mas_matrix_secret
- key: mas_encryption
path: mas_encryption
- key: mas_rsa_key
path: mas_rsa_key
- key: mas_ec_key
path: mas_ec_key
- name: pg
secret:
secretName: mx-pg-app
items:
- key: password
path: password
---
apiVersion: v1
kind: Service
metadata:
name: mas
namespace: matrix
spec:
selector:
app.kubernetes.io/name: mas
ports:
- name: http
port: 8080
targetPort: http
---
# `mas` database in mx-pg, owned by the synapse role (one app, one
# namespace), so MAS reuses mx-pg-app. Barman backs it up with synapse.
apiVersion: postgresql.cnpg.io/v1
kind: Database
metadata:
name: mx-pg-mas
namespace: matrix
spec:
cluster:
name: mx-pg
name: mas
owner: synapse
+30
View File
@@ -0,0 +1,30 @@
---
apiVersion: barmancloud.cnpg.io/v1
kind: ObjectStore
metadata:
name: mx-pg-store
namespace: matrix
spec:
configuration:
# Offsite Hetzner Object Storage (fsn1), same bucket as the other CNPG
# clusters. No SSE: Hetzner supports only SSE-C, unusable by barman-cloud
# (plugin #646), so at-rest encryption is unavailable; transit is TLS.
destinationPath: s3://renner-uno-k8s-cnpg/mx-pg
endpointURL: https://fsn1.your-objectstorage.com
s3Credentials:
accessKeyId:
name: hetzner-s3-creds
key: ACCESS_KEY_ID
secretAccessKey:
name: hetzner-s3-creds
key: ACCESS_SECRET_KEY
# Region is required (REGION=fsn1) — without it boto3's HeadBucket
# (barman-cloud-check-wal-archive during bootstrap.recovery) 400s.
region:
name: hetzner-s3-creds
key: REGION
wal:
compression: gzip
data:
compression: gzip
retentionPolicy: "30d"
@@ -0,0 +1,16 @@
apiVersion: postgresql.cnpg.io/v1
kind: ScheduledBackup
metadata:
name: mx-pg-daily
namespace: matrix
spec:
# 03:00 local, same slot as the other CNPG clusters (the Velero PVC
# schedule for this namespace runs later, at 09:45).
schedule: "0 0 3 * * *"
immediate: true
backupOwnerReference: self
cluster:
name: mx-pg
method: plugin
pluginConfiguration:
name: barman-cloud.cloudnative-pg.io
+324
View File
@@ -0,0 +1,324 @@
# Synapse homeserver for matrix.renner.uno (REN-567).
#
# Private: federation is off at three layers — federation_domain_whitelist
# is empty, no listener serves the federation/keys resources, and the
# namespace egress policy lets Synapse reach nothing outside the cluster
# except the push gateway. Logins and accounts are delegated to MAS
# (mas.yaml); registration is closed.
#
# server_name is permanent: it is part of every user and room ID, and
# cannot be changed without a new, empty server. matrix.renner.uno needs no
# .well-known delegation from the apex, which is the WordPress site.
apiVersion: v1
kind: ConfigMap
metadata:
name: synapse-config
namespace: matrix
data:
homeserver.yaml: |
server_name: matrix.renner.uno
public_baseurl: https://matrix.renner.uno/
# Lets Element X and other clients discover the homeserver from the
# server name. No server well-known: there is no federation to point at.
serve_client_wellknown: true
pid_file: /tmp/homeserver.pid
report_stats: false
listeners:
# Client API only (includes media and /.well-known). Leaving out the
# `federation` and `keys` resources means this server does not answer
# federation at all.
- port: 8008
type: http
tls: false
bind_addresses: ["::"]
x_forwarded: true
resources:
- names: [client]
compress: false
# The password comes from PGPASSWORD (libpq reads it), so no credential
# is written into this file.
database:
name: psycopg2
args:
host: mx-pg-rw
port: 5432
dbname: synapse
user: synapse
cp_min: 2
cp_max: 10
# Signing key is generated on first start if missing; it lives on the
# data PVC next to the media store, so Velero backs up both.
signing_key_path: /data/signing.key
media_store_path: /data/media_store
max_upload_size: 100M
# Also the macaroon key: Synapse falls back to it when
# macaroon_secret_key is unset, so rotating it logs every session out.
registration_shared_secret_path: /secrets/registration_shared_secret
# MAS handles login, sessions and accounts. Synapse asks it to check
# every access token; password login here must be off.
matrix_authentication_service:
enabled: true
endpoint: http://mas:8080/
secret_path: /secrets/mas_matrix_secret
password_config:
enabled: false
# Sign in with QR code (Element X): the rendezvous channel between the
# new and the signed-in device. Both require MAS. `open` lets the new,
# not-yet-signed-in device create the channel; the server is LAN-only.
experimental_features:
msc4108_enabled: true
msc4388_mode: open
# Federation off.
federation_domain_whitelist: []
trusted_key_servers: []
allow_public_rooms_over_federation: false
enable_registration: false
allow_guest_access: false
url_preview_enabled: false
user_directory:
search_all_users: true
# Phones get pushes through the Element push gateway on matrix.org.
# Only event and room IDs leave the cluster, never message text.
push:
include_content: false
# Appservice registrations (bridges), one file each, mounted from a
# Secret. matrix-bridge: bridge.yaml (REN-587).
app_service_config_files:
- /appservices/matrix-bridge/registration.yaml
---
# Media store and the server signing key. Not reconstructable: lost media
# is gone, and a lost signing key invalidates the server's past signatures.
# Backed up by Velero (matrix-daily); the database by Barman (mx-pg).
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
name: synapse-data
namespace: matrix
labels:
app.kubernetes.io/name: synapse
spec:
accessModes:
- ReadWriteOnce
storageClassName: ceph-block
resources:
requests:
storage: 10Gi
---
apiVersion: apps/v1
kind: Deployment
metadata:
name: synapse
namespace: matrix
annotations:
configmap.reloader.stakater.com/reload: synapse-config,mas-config
secret.reloader.stakater.com/reload: synapse-secrets,matrix-bridge-tokens
labels:
app.kubernetes.io/name: synapse
app.kubernetes.io/part-of: matrix
spec:
replicas: 1
strategy:
type: Recreate
selector:
matchLabels:
app.kubernetes.io/name: synapse
template:
metadata:
labels:
app.kubernetes.io/name: synapse
app.kubernetes.io/part-of: matrix
spec:
automountServiceAccountToken: false
securityContext:
runAsNonRoot: true
runAsUser: 991
runAsGroup: 991
fsGroup: 991
seccompProfile:
type: RuntimeDefault
initContainers:
# One-time move of the Synapse accounts (owner, password hash,
# sessions) into the MAS database. syn2mas needs Synapse offline;
# this runs before Synapse starts, and Recreate stops the old pod
# first. The marker on the data PVC makes later starts skip it.
# Debug image: the plain one has no shell for the marker check.
- name: migrate-to-mas
image: ghcr.io/element-hq/matrix-authentication-service:1.26.0-debug@sha256:46f7480f5ea4243ccb6fd2c447ea859e0230c8b3c0e676ee285d4ae6ca344ee3
command:
- /busybox/sh
- -ec
- |
if [ -f /data/.syn2mas-done ]; then
echo "syn2mas already done"; exit 0
fi
mas-cli syn2mas migrate \
--config /mas-config/config.yaml \
--synapse-config /config/homeserver.yaml \
--synapse-database-uri postgresql:
touch /data/.syn2mas-done
securityContext:
allowPrivilegeEscalation: false
readOnlyRootFilesystem: true
capabilities:
drop: ["ALL"]
env:
# libpq-style variables for the Synapse database; the URI above
# is empty on purpose.
- name: PGHOST
value: mx-pg-rw
- name: PGUSER
value: synapse
- name: PGDATABASE
value: synapse
- name: PGPASSWORD
valueFrom:
secretKeyRef:
name: mx-pg-app
key: password
resources:
requests:
cpu: 10m
memory: 64Mi
limits:
memory: 256Mi
volumeMounts:
- name: config
mountPath: /config
readOnly: true
- name: mas-config
mountPath: /mas-config
readOnly: true
- name: secrets
mountPath: /secrets
readOnly: true
- name: pg
mountPath: /pg
readOnly: true
- name: data
mountPath: /data
containers:
- name: synapse
image: ghcr.io/element-hq/synapse:v1.162.0@sha256:6b84a7bbac36f080b2d2e51e0289cf1b08b349598ea44a558df38d558f2c2311
# Bypass /start.py: it expects to run as root and template a config
# from env. Default mode is generate-missing-and-run, which creates
# the signing key on first start.
command:
- python
- -m
- synapse.app.homeserver
- --config-path
- /config/homeserver.yaml
securityContext:
allowPrivilegeEscalation: false
readOnlyRootFilesystem: true
capabilities:
drop: ["ALL"]
env:
- name: PGPASSWORD
valueFrom:
secretKeyRef:
name: mx-pg-app
key: password
ports:
- name: http
containerPort: 8008
resources:
requests:
cpu: 100m
memory: 256Mi
limits:
memory: 1Gi
# First start runs every schema migration against an empty
# database; give it up to 10 min.
startupProbe:
httpGet:
path: /health
port: http
periodSeconds: 10
failureThreshold: 60
readinessProbe:
httpGet:
path: /health
port: http
periodSeconds: 10
livenessProbe:
httpGet:
path: /health
port: http
periodSeconds: 30
timeoutSeconds: 5
failureThreshold: 4
volumeMounts:
- name: config
mountPath: /config
readOnly: true
- name: secrets
mountPath: /secrets
readOnly: true
- name: data
mountPath: /data
- name: tmp
mountPath: /tmp
- name: appservice-matrix-bridge
mountPath: /appservices/matrix-bridge
readOnly: true
volumes:
- name: config
configMap:
name: synapse-config
- name: secrets
secret:
secretName: synapse-secrets
items:
- key: registration_shared_secret
path: registration_shared_secret
- key: mas_matrix_secret
path: mas_matrix_secret
- key: mas_encryption
path: mas_encryption
- key: mas_rsa_key
path: mas_rsa_key
- key: mas_ec_key
path: mas_ec_key
- name: mas-config
configMap:
name: mas-config
- name: pg
secret:
secretName: mx-pg-app
items:
- key: password
path: password
- name: data
persistentVolumeClaim:
claimName: synapse-data
- name: tmp
emptyDir: {}
- name: appservice-matrix-bridge
secret:
secretName: matrix-bridge-tokens
items:
- key: registration.yaml
path: registration.yaml
---
apiVersion: v1
kind: Service
metadata:
name: synapse
namespace: matrix
spec:
selector:
app.kubernetes.io/name: synapse
ports:
- name: http
port: 8008
targetPort: http
@@ -1,8 +1,8 @@
---
# Cilium's agent ServiceMonitor, declared here rather than by the chart.
#
# Reproduces what cilium 1.20.1 renders with prometheus.serviceMonitor.enabled,
# taken field for field off the live object so scraping is unchanged: same name,
# same namespace, same selector, same 10s interval and node relabeling.
# Reproduces what cilium renders with prometheus.serviceMonitor.enabled: same
# name, same namespace, same 10s interval and node relabeling.
#
# It lives here because the chart's template is gated on monitoring.coreos.com/v1
# existing at install time, and on an empty cluster it does not — those CRDs
@@ -22,13 +22,16 @@ metadata:
app.kubernetes.io/part-of: cilium
spec:
selector:
# The headless `cilium-agent` Service that the HelmRelease renders with
# prometheus.metricsService (REN-166). It carries k8s-app: cilium, which
# targetLabels below copies onto every series; the dashboard the chart
# ships queries cilium_bpf_map_pressure{k8s_app="cilium"}.
matchLabels:
app.kubernetes.io/name: cilium-agent
app.kubernetes.io/part-of: cilium
namespaceSelector:
matchNames:
- kube-system
# The chart's Service keeps rendering (prometheus.enabled), so the target and
# its `metrics` port are there regardless of who declares the ServiceMonitor.
targetLabels:
- k8s-app
endpoints:
@@ -0,0 +1,82 @@
# Scrape the external-secrets (ESO) controller's own metrics. Until this
# existed, nothing in this cluster could see a failed ExternalSecret sync:
# `externalsecret_status_condition` held 0 series, so no rule could be written
# about a key that silently stops syncing (REN-100).
#
# This is the scrape only. The alert rule is deliberately NOT in this change —
# its `for:` window has to be tuned against real data, and that data does not
# exist until this has been live for a while. See REN-103.
#
# A PodMonitor, NOT the chart's `serviceMonitor.enabled`, and NOT a hand-written
# ServiceMonitor. Both alternatives were checked against chart 2.11.0:
#
# * A hand-written ServiceMonitor has nothing to select. `metrics.service.enabled`
# defaults to false and infrastructure/external-secrets/helmrelease.yaml
# overrides nothing, so templates/service.yaml renders no Service for the
# controller. The container port exists (`name: metrics`, containerPort 8080)
# but nothing fronts it — the same trap that forced a PodMonitor for the Flux
# controllers.
# * Setting `serviceMonitor.enabled: true` would work, but it triggers a Helm
# UPGRADE of ESO, which re-renders the Deployment and re-applies its CRDs
# (`crds: CreateReplace` in the HelmRelease). ESO is what all 54 ExternalSecret
# manifests in this repo depend on. A PodMonitor gets the same series while
# touching the release not at all, which is the trade this repo already made
# for Velero's node-agent (velero-podmonitor.yaml) and for Flux.
#
# THIS NEEDS A NETWORK POLICY CHANGE, unlike the Flux PodMonitor: the cluster is
# default-deny and external-secrets-ns.yaml admitted only intra-namespace traffic,
# host/remote-node and ICMP — no `monitoring` grant, so this scrape would have
# been dropped and the metric would have stayed absent. The matching ingress rule
# is added to infrastructure/network-policies/external-secrets-ns.yaml in the
# same pull request. Without it this file is decoration.
#
# NO TLS AND NO AUTH ON THIS SCRAPE, and that is the chart's posture rather than
# an omission here. In 2.11.0 `metrics.listen.secure.enabled` and
# `metrics.listen.auth.enabled` are both false in the chart's values.yaml and
# infrastructure/external-secrets/helmrelease.yaml overrides neither, so the
# controller serves /metrics over plain HTTP to anything that can reach :8080.
# Hence no `scheme`, no `tlsConfig` and no `bearerTokenSecret` below: adding
# them would break the scrape, not harden it. What limits exposure is the
# network policy — a single port from a single namespace — so turning on
# `secure.enabled` here would mean a Helm upgrade of ESO to close a hole the
# CiliumNetworkPolicy already closes.
apiVersion: monitoring.coreos.com/v1
kind: PodMonitor
metadata:
name: external-secrets
namespace: monitoring
labels:
app.kubernetes.io/name: external-secrets
# Not required for discovery — podMonitorSelector is empty, see
# apps/monitoring/helmrelease-prometheus.yaml — but set for consistency with
# the other monitors in this directory.
release: kube-prometheus-stack
spec:
# Lives in `monitoring` rather than in `external-secrets`, matching
# external-dns-servicemonitor.yaml and the Flux PodMonitor. Every object in
# the external-secrets namespace is owned by the ESO HelmRelease; keeping this
# out of that namespace means this change cannot interact with the release.
namespaceSelector:
matchNames:
- external-secrets
selector:
matchLabels:
# The CONTROLLER only. The webhook and cert-controller carry
# `app.kubernetes.io/name: external-secrets-webhook` and
# `-cert-controller` respectively (see the chart's
# external-secrets-webhook.selectorLabels / -cert-controller.selectorLabels
# helpers), so an exact match on the unsuffixed name excludes both. That is
# intended: the `externalsecret_*` series are emitted by the controller, and
# the other two would only add idle targets.
app.kubernetes.io/name: external-secrets
app.kubernetes.io/instance: external-secrets
podMetricsEndpoints:
# Named container port, not a hardcoded 8080, so this follows
# `metrics.listen.port` if it is ever overridden in the HelmRelease.
- port: metrics
# 60s, not the chart's 30s default: `externalsecret_status_condition` is a
# slow-moving gauge over ~54 ExternalSecrets, and the alert built on it in
# REN-103 will use a multi-minute `for:` window. 30s would double the
# samples for no gain in detection time.
interval: 60s
scrapeTimeout: 10s
@@ -0,0 +1,91 @@
# Scrape the Flux controllers' own metrics. Until this existed Prometheus held
# no `gotk_*` series at all, so nothing about Flux's own behaviour was
# queryable and no rule could be written about it (REN-97).
#
# THIS IS THE SCRAPE ONLY, and the readiness alert is not merely deferred —
# it cannot be written from this endpoint. `gotk_reconcile_condition` and
# `gotk_suspend_status` are still DECLARED by fluxcd/pkg/runtime (v0.110.3,
# runtime/metrics/recorder.go), but at the tags pinned in gotk-components.yaml
# no controller calls the recorder that populates them: grepping the six
# tagged source trees for RecordReadiness / RecordCondition / RecordSuspend
# returns zero call sites, and an unpopulated GaugeVec exports no series. So
# the readiness metrics would stay empty however this file is written. Flux
# moved per-object readiness to kube-state-metrics custom-resource-state
# (`gotk_resource_info{ready=...}`); that is REN-102, and it is a prerequisite
# for the not-Ready alert rather than a follow-up to it.
#
# What this scrape does yield, and why it is still worth merging on its own:
# * `gotk_reconcile_duration_seconds` per kind/name/namespace — reconcile
# latency and, by its absence, an object that has stopped being reconciled
# at all. RecordDuration IS called, but by FIVE of the six controllers, not
# all six: measured post-merge, 170 series from kustomize (33), source (43),
# image-reflector (68), image-automation (1) and helm (25), and ZERO from
# notification-controller. That is not a gap waiting to fill in — its three
# reconcilers are registered but never walked (controller_runtime_reconcile_
# total for controller=alert/provider/receiver is 0 over 56 h of uptime with
# 2 Alerts and 1 Provider live), so the family is absent from that pod's
# /metrics entirely and five is the permanent value. DO NOT write a rule of
# the form `count(... gotk_reconcile_duration_seconds ...) < 6`, or an
# absent() per pod: it fires forever on notification-controller. Liveness for
# all six pods is `up{job="monitoring/flux-controllers"}` (below); that pod's
# reconcile health is `controller_runtime_reconcile_errors_total`. REN-127.
# * controller-runtime's own series: reconcile totals and errors per
# controller, workqueue depth and retry counts, leader election.
# * the target itself, so `up{job="monitoring/flux-controllers"}` and the
# chart's default TargetDown rule start covering the Flux control plane.
# * the scrape REN-102 needs in place anyway.
#
# A PodMonitor, NOT a ServiceMonitor, and that is forced rather than preferred:
# gotk-components.yaml creates Services for only two of the six controllers
# (source-controller, notification-controller), and both publish port 80 ->
# targetPort `http`, which is the artifact/webhook server on :9090 — not the
# metrics port. kustomize-, helm-, image-reflector- and image-automation-
# controller have no Service at all, so there is nothing for a ServiceMonitor to
# select. All six pods do carry the same two labels and the same `http-prom`
# (:8080) container port, so one PodMonitor covers the set.
#
# NO NETWORK POLICY CHANGE IS NEEDED, verified rather than assumed, and unlike
# external-secrets-podmonitor.yaml which did need one: flux-system has no
# CiliumNetworkPolicy of its own (infrastructure/network-policies/ has no
# flux-system file), and gotk-components.yaml ships an `allow-scraping`
# NetworkPolicy admitting every namespace to :8080 (`from: [namespaceSelector:
# {}]`, port 8080). So `monitoring` is already admitted, as it was for REN-21.
# Nothing in the Flux install is touched.
apiVersion: monitoring.coreos.com/v1
kind: PodMonitor
metadata:
name: flux-controllers
namespace: monitoring
labels:
app.kubernetes.io/part-of: flux
# Not required for discovery — podMonitorSelector is empty, see
# apps/monitoring/helmrelease-prometheus.yaml — but set for consistency
# with the other monitors in this directory.
release: kube-prometheus-stack
spec:
# Lives in `monitoring` with a namespaceSelector rather than in flux-system,
# matching external-dns-servicemonitor.yaml and external-secrets-podmonitor.yaml.
# Flux owns every object in flux-system via gotk-components.yaml; keeping this
# out of that namespace means this change cannot interact with the Flux install
# itself.
namespaceSelector:
matchNames:
- flux-system
selector:
matchLabels:
app.kubernetes.io/part-of: flux
app.kubernetes.io/instance: flux-system
podMetricsEndpoints:
# Matches the controllers' `http-prom` port (containerPort 8080). Present on
# all six Deployments in gotk-components.yaml; a future controller without
# it simply yields no target rather than a broken scrape config.
- port: http-prom
path: /metrics
# 60s, not the 30s used elsewhere here, matching the ESO PodMonitor: the
# useful series are slow-moving per-object gauges and histograms over a
# few hundred Flux objects, and any rule built on them (REN-102) will use
# a multi-minute `for:`. 30s would double the samples for no gain in
# detection time — and Prometheus is already near its retention cap
# (REN-107).
interval: 60s
scrapeTimeout: 10s

Some files were not shown because too many files have changed in this diff Show More