docs(infra): cut the narration out of cephcluster and the velero schedules

Comments only — filtering the diff for non-comment lines returns empty, and both files still parse and build. cephcluster.yaml goes from 224 comment lines to 76. Kept: that `ceph config` retains values which merely disappear from this file, so deleting a line does not restore a default and a live provider change needs `ceph config rm` first; that osdMaxUpdatesInParallel and upgradeOSDRequiresHealthyPGs are the only things keeping a rolling OSD change off all three replicas at once; that `addressRanges` drags the mons onto host networking and ties them to a DHCP lease; that devices are named by-id because kernel names move between boots; that the bluestore deferral settings must not be raised again. Cut from it: the paxos write-amplification measurement down to the byte, the history of why mon_data_avail_warn was once 20, and a table of every drive serial in the fleet sitting three lines above the by-id paths that already name them. velero-schedules.yaml loses a per-PVC inventory of the home-assistant namespace — eleven names, which had already been wrong once by two — in favour of saying the schedule sweeps the namespace. Two stale claims went with it. Both files said PVC contents are uploaded to Garage; the BackupStorageLocation reads bucket renner-uno-k8s-velero at fsn1.your-objectstorage.com, and Garage was retired to nas-1. And the ha-pg exclusion still explained itself by quoting the comment it had replaced.
Merge pull request 'docs(talos): cut the narration out of the machine config patches' (#680 ) from trim-comments-talos into master
2026-08-28 06:39:44 +02:00 · 2026-08-28 04:34:43 +00:00 · 2026-08-28 06:27:57 +02:00 · 2026-08-28 04:21:02 +00:00 · 2026-08-28 04:20:33 +00:00 · 2026-08-27 19:45:14 +00:00
23 changed files with 330 additions and 699 deletions
@@ -1,18 +0,0 @@
-apiVersion: external-secrets.io/v1
-kind: ExternalSecret
-metadata:
-  name: barman-cloud-creds
-  namespace: authentik
-  annotations:
-    # Prune-disabled — a standing guard kept from the seed->authentik-KS handoff (barman creds).
-    kustomize.toolkit.fluxcd.io/prune: disabled
-spec:
-  refreshInterval: 1h
-  secretStoreRef:
-    kind: ClusterSecretStore
-    name: openbao
-  target:
-    name: barman-cloud-creds # keeps the old Secret's name — consumers unchanged
-  dataFrom:
-    - extract:
-        key: seed/authentik/barman-creds
@@ -15,4 +15,4 @@ spec:
    name: hetzner-s3-creds # keeps the old Secret's name — consumers unchanged
  dataFrom:
    - extract:
-        key: seed/authentik/hetzner-creds
+        key: infrastructure/hetzner-s3
@@ -27,5 +27,4 @@ resources:
  - cluster.yaml
  - objectstore.yaml
  - scheduled-backup.yaml
-  - barman-creds-externalsecret.yaml
  - hetzner-creds-externalsecret.yaml
@@ -1,21 +1,8 @@
 ---
 # Barman S3 credentials for ha-pg.
 #
-# FOLLOW-UP (#397): sourced from seed/paperless/hetzner-creds, which is not where
-# they belong. woodpecker/hetzner-creds-externalsecret.yaml has the identical
-# problem and the same note. The values are the same today, so this is correct
-# but coupled: rotating paperless's Hetzner credentials would silently change
-# the backup credentials for Home Assistant and Woodpecker too.
-#
-# The fix is one dedicated path per consumer (seed/home-assistant/hetzner-creds)
-# and a one-line change to the `key:` below. Creating it needs an OpenBao write:
-#
-#   bao kv put homelab/seed/home-assistant/hetzner-creds \
-#     @<(bao kv get -format=json homelab/seed/paperless/hetzner-creds | jq '.data.data')
-#
-# Note the mount is `homelab`, so the path is homelab/seed/... — #397 records a
-# 403 on `bao kv list seed`, which was a wrong-path error rather than a
-# permissions problem.
+# One shared path for one shared credential — see the note in
+# ../paperless/hetzner-creds-externalsecret.yaml.
 #
 # The namespace allowlist on the openbao ClusterSecretStore
 # (infrastructure/post-crds/openbao-clustersecretstore.yaml) must include this
@@ -35,4 +22,4 @@ spec:
    name: hetzner-s3-creds
  dataFrom:
    - extract:
-        key: seed/paperless/hetzner-creds
+        key: infrastructure/hetzner-s3
@@ -1,18 +0,0 @@
-apiVersion: external-secrets.io/v1
-kind: ExternalSecret
-metadata:
-  name: barman-cloud-creds
-  namespace: immich
-  annotations:
-    # Prune-disabled — a standing guard kept from the seed->immich-KS handoff (barman creds).
-    kustomize.toolkit.fluxcd.io/prune: disabled
-spec:
-  refreshInterval: 1h
-  secretStoreRef:
-    kind: ClusterSecretStore
-    name: openbao
-  target:
-    name: barman-cloud-creds # keeps the old Secret's name — consumers unchanged
-  dataFrom:
-    - extract:
-        key: seed/immich/barman-creds
@@ -15,4 +15,4 @@ spec:
    name: hetzner-s3-creds # keeps the old Secret's name — consumers unchanged
  dataFrom:
    - extract:
-        key: seed/immich/hetzner-creds
+        key: infrastructure/hetzner-s3
@@ -13,6 +13,5 @@ resources:
  - cluster.yaml
  - objectstore.yaml
  - scheduled-backup.yaml
-  - barman-creds-externalsecret.yaml
  - hetzner-creds-externalsecret.yaml
  - pvcs.yaml
@@ -11,25 +11,10 @@ spec:
  groups:
    - name: disk-wear.rules
      rules:
-        # THE GAP THESE RULES CLOSE
-        #
-        # Drive wear is invisible in every other signal this cluster has.
-        # `ceph -s` reads active+clean at any wear level, no Ceph health check
-        # fires until a device actually fails, and the block-layer metrics show
-        # throughput and latency but never endurance. That blind spot is how a
-        # set of OSD drives reached 81-87% before anyone looked (#549, #434).
-        #
-        # The numbers below are wear percentages reported by the drive itself:
-        # 100 means the manufacturer's rated endurance is used up. Drives do
-        # not stop at 100 — they typically keep working and start consuming
-        # spare blocks — so treat these as planning thresholds, not failure
-        # predictions.
+        # Wear percentages are self-reported: 100 means the rated endurance is
+        # spent, not that the drive stops. Planning thresholds, not predictions.
        - alert: NvmeDriveWearHigh
-          # 80% with months of runway left is the point where ordering a
-          # replacement is still a calm decision rather than an outage.
-          # `for` is long because wear is monotonic and slow: it cannot
-          # flap, and a short window would only make the alert noisier
-          # after a restart.
+          # Long `for` because wear is monotonic and cannot flap.
          expr: smartctl_device_percentage_used >= 80
          for: 1h
          labels:
@@ -37,12 +22,11 @@ spec:
          annotations:
            summary: "NVMe {{ $labels.device }} on {{ $labels.instance }} is at {{ $value }}% rated wear"
            description: >-
-              The drive has used {{ $value }}% of its rated write endurance.
-              Nothing is failing and no data is at risk yet. Check what the
-              drive is carrying before deciding urgency: an OSD is replaceable
-              with a rebalance, whereas the EPHEMERAL volume has no such
-              escape — a node simply stops when it goes. The Disk Health
-              dashboard resolves which drive holds which role.
+              {{ $value }}% of rated write endurance used. Nothing is failing
+              yet. Urgency depends on what the drive carries — the Disk Health
+              dashboard shows the role. Losing an OSD costs a rebalance;
+              EPHEMERAL is /var and rebuilds, apart from the node's etcd member
+              data, which has to be removed and re-added.
        - alert: NvmeDriveWearCritical
          expr: smartctl_device_percentage_used >= 95
          for: 1h
@@ -55,9 +39,7 @@ spec:
              likely keep working for a while, but it is now operating outside
              what the manufacturer stands behind, and replacement should be
              scheduled rather than considered.
-        # A drive that has consumed its spare area is no longer masking media
-        # defects, which is a materially different state from being worn:
-        # wear is a budget, spare exhaustion is damage.
+        # Wear is a budget; spare exhaustion is damage.
        - alert: NvmeDriveSpareExhausted
          expr: smartctl_device_available_spare <= smartctl_device_available_spare_threshold
          for: 15m
@@ -70,10 +52,6 @@ spec:
              drive has run out of reserve blocks to remap failures into.
              Replace it.
        - alert: NvmeDriveCriticalWarning
-          # The NVMe critical warning byte is a bitfield: spare below
-          # threshold, temperature out of range, degraded reliability,
-          # read-only mode, volatile-memory backup failed. Any non-zero value
-          # is the drive itself asking for attention.
          expr: smartctl_device_critical_warning > 0
          for: 5m
          labels:
@@ -85,10 +63,8 @@ spec:
              detail with `smartctl -a` on the node; the value is a bitfield,
              not a count.
        - alert: NvmeDriveMediaErrors
-          # Unlike wear, this counter should never move. Alert on the increase
-          # rather than the absolute value, so a drive that recorded errors
-          # long ago does not alert forever while a drive that starts failing
-          # today does.
+          # On the increase, not the total: pre-existing errors would otherwise
+          # alert forever. Standing counts are visible on the dashboard only.
          expr: increase(smartctl_device_media_errors[6h]) > 0
          for: 5m
          labels:
@@ -99,14 +75,9 @@ spec:
              The drive reported unrecoverable data-integrity errors in the
              last six hours. A healthy drive never increments this. Check
              whether Ceph has logged scrub errors on the same node.
-        # Without this the whole group is silently useless: no series means no
-        # alert fires, and a dashboard of empty panels reads much like a
-        # healthy one. This is the check that the checks are running.
+        # The check that the checks are running: no series fires no alert.
+        # Counted against node-exporter's inventory, not a fixed fleet size.
        - alert: SmartctlExporterIncomplete
-          # Compared against node-exporter's own NVMe inventory rather than a
-          # written-down fleet size. Adding or removing a drive then moves both
-          # sides together, so this cannot rot into a permanent false alarm the
-          # way a hardcoded count would.
          expr: count(smartctl_device_percentage_used) < count(node_nvme_info) or absent(smartctl_device_percentage_used)
          for: 30m
          labels:
@@ -14,16 +14,12 @@ spec:
    matchLabels:
      app.kubernetes.io/name: smartctl-exporter
  endpoints:
-    # smartctl itself polls the drives every 60s, so scraping faster than that
-    # returns the same numbers with a new timestamp. Wear moves on a scale of
-    # weeks; 60s is already far finer than the signal.
+    # smartctl polls the drives every 60s; scraping faster gains nothing.
    - port: http-metrics
      path: /metrics
      interval: 60s
      relabelings:
-        # Without this every series is labelled with the exporter pod's IP and
-        # nothing else. A DaemonSet pod's IP says nothing about which machine
-        # the drive is in, and it changes on every reschedule — so the wear
-        # figure would be unattributable, which is most of its value gone.
+        # Without this a series carries only the exporter pod's IP, which does
+        # not identify the machine the drive is in.
        - sourceLabels: [__meta_kubernetes_pod_node_name]
          targetLabel: node
@@ -1,6 +1,6 @@
 {
  "annotations": {"list": []},
-  "description": "NVMe health and performance per node. The top row answers 'is anything wrong'; the graphs below answer 'why'. Panels resolve each drive through node_nvme_info and node_uname_info rather than plotting the Linux device name, because NVMe enumeration order is not guaranteed to agree across machines — the same name can be a different drive on the next node. Which drive currently holds which role is in the inventory table, deliberately not in this text. Endurance/wear is absent; see the note at the bottom and issue #549.",
+  "description": "NVMe health and performance per node. The top row answers 'is anything wrong'; the graphs below answer 'why'. Panels resolve each drive through node_nvme_info and node_uname_info rather than plotting the Linux device name, because NVMe enumeration order is not guaranteed to agree across machines — the same name can be a different drive on the next node. Which drive currently holds which role is in the inventory table, deliberately not in this text. Endurance comes from smartctl_exporter, whose series are labelled by node rather than by the exporter pod's IP — see the note at the bottom for what it still cannot tell you.",
  "editable": true,
  "fiscalYearStartMonth": 0,
  "graphTooltip": 1,
@@ -19,7 +19,7 @@
        },
        "overrides": []
      },
-      "gridPos": {"h": 4, "w": 6, "x": 0, "y": 0},
+      "gridPos": {"h": 4, "w": 5, "x": 0, "y": 0},
      "id": 10,
      "options": {"colorMode": "background", "graphMode": "none", "justifyMode": "auto", "orientation": "auto", "reduceOptions": {"calcs": ["lastNotNull"], "fields": "", "values": false}, "textMode": "auto"},
      "targets": [{"datasource": {"type": "prometheus", "uid": "prometheus"}, "expr": "ceph_health_status", "legendFormat": "", "refId": "A"}],
@@ -28,7 +28,7 @@
    },
    {
      "datasource": {"type": "prometheus", "uid": "prometheus"},
-      "description": "OSDs the cluster knows about but which are not up, and not in. Both should read zero. Counted as a difference against ceph_osd_metadata rather than compared to a fixed number, so adding or removing an OSD does not turn this panel into a false alarm.",
+      "description": "OSDs the cluster knows about but which are not up. Should read zero. Counted as a difference against ceph_osd_metadata rather than compared to a fixed number, so adding or removing an OSD does not turn this panel into a false alarm. An OSD that is up but out shows as a Ceph health warning instead — it is a state, not a fault, and it does not belong in a red-or-green box.",
      "fieldConfig": {
        "defaults": {
          "color": {"mode": "thresholds"},
@@ -38,14 +38,13 @@
        },
        "overrides": []
      },
-      "gridPos": {"h": 4, "w": 6, "x": 6, "y": 0},
+      "gridPos": {"h": 4, "w": 5, "x": 5, "y": 0},
      "id": 11,
      "options": {"colorMode": "background", "graphMode": "none", "justifyMode": "auto", "orientation": "auto", "reduceOptions": {"calcs": ["lastNotNull"], "fields": "", "values": false}, "textMode": "auto"},
      "targets": [
-        {"datasource": {"type": "prometheus", "uid": "prometheus"}, "expr": "sum(ceph_osd_metadata) - sum(ceph_osd_up)", "legendFormat": "down", "refId": "A"},
-        {"datasource": {"type": "prometheus", "uid": "prometheus"}, "expr": "sum(ceph_osd_metadata) - sum(ceph_osd_in)", "legendFormat": "out", "refId": "B"}
+        {"datasource": {"type": "prometheus", "uid": "prometheus"}, "expr": "sum(ceph_osd_metadata) - sum(ceph_osd_up)", "legendFormat": "", "refId": "A"}
      ],
-      "title": "OSDs down / out",
+      "title": "OSDs down",
      "type": "stat"
    },
    {
@@ -62,7 +61,7 @@
        },
        "overrides": []
      },
-      "gridPos": {"h": 4, "w": 6, "x": 12, "y": 0},
+      "gridPos": {"h": 4, "w": 5, "x": 10, "y": 0},
      "id": 12,
      "options": {"colorMode": "background", "graphMode": "area", "justifyMode": "auto", "orientation": "auto", "reduceOptions": {"calcs": ["lastNotNull"], "fields": "", "values": false}, "textMode": "auto"},
      "targets": [{"datasource": {"type": "prometheus", "uid": "prometheus"}, "expr": "ceph_cluster_total_used_bytes / ceph_cluster_total_bytes", "legendFormat": "", "refId": "A"}],
@@ -71,7 +70,7 @@
    },
    {
      "datasource": {"type": "prometheus", "uid": "prometheus"},
-      "description": "Fullest EPHEMERAL volume across the fleet — Talos's /var, holding container images, pod scratch space and kubelet state. A full /var takes the node down, and unlike Ceph nothing rebalances away from it.",
+      "description": "Fullest EPHEMERAL volume across the fleet — Talos's /var. Its contents are meant to be disposable: container images, kubelet state and pod scratch all rebuild. Filling it is still a problem, because a node with no room to write stops being useful long before anything is lost, and nothing rebalances /var the way Ceph rebalances a full OSD.",
      "fieldConfig": {
        "defaults": {
          "color": {"mode": "thresholds"},
@@ -83,7 +82,7 @@
        },
        "overrides": []
      },
-      "gridPos": {"h": 4, "w": 6, "x": 18, "y": 0},
+      "gridPos": {"h": 4, "w": 5, "x": 15, "y": 0},
      "id": 13,
      "options": {"colorMode": "background", "graphMode": "area", "justifyMode": "auto", "orientation": "auto", "reduceOptions": {"calcs": ["lastNotNull"], "fields": "", "values": false}, "textMode": "auto"},
      "targets": [{"datasource": {"type": "prometheus", "uid": "prometheus"}, "expr": "max(1 - node_filesystem_avail_bytes{mountpoint=\"/var\"} / node_filesystem_size_bytes{mountpoint=\"/var\"})", "legendFormat": "", "refId": "A"}],
@@ -115,7 +114,7 @@
          "refId": "A"
        }
      ],
-      "title": "Drive inventory",
+      "title": "Drive inventory (identity and role)",
      "transformations": [
        {
          "id": "organize",
@@ -128,6 +127,100 @@
      ],
      "type": "table"
    },
+    {
+      "datasource": {"type": "prometheus", "uid": "prometheus"},
+      "description": "Rated endurance consumed, worst drive in the fleet. This is the drive's own accounting against what the manufacturer warrants, not a failure prediction — a drive past 100 usually keeps working and starts eating its spare area. Read it for planning; read the SMART table for whether anything is failing now.",
+      "fieldConfig": {
+        "defaults": {
+          "color": {"mode": "thresholds"},
+          "mappings": [],
+          "max": 100,
+          "min": 0,
+          "thresholds": {"mode": "absolute", "steps": [{"color": "green", "value": null}, {"color": "orange", "value": 80}, {"color": "red", "value": 95}]},
+          "unit": "percent"
+        },
+        "overrides": []
+      },
+      "gridPos": {"h": 4, "w": 4, "x": 20, "y": 0},
+      "id": 14,
+      "options": {"colorMode": "background", "graphMode": "area", "justifyMode": "auto", "orientation": "auto", "reduceOptions": {"calcs": ["lastNotNull"], "fields": "", "values": false}, "textMode": "auto"},
+      "targets": [{"datasource": {"type": "prometheus", "uid": "prometheus"}, "expr": "max(smartctl_device_percentage_used)", "legendFormat": "", "refId": "A"}],
+      "title": "Worst NVMe wear",
+      "type": "stat"
+    },
+    {
+      "datasource": {"type": "prometheus", "uid": "prometheus"},
+      "description": "Rated endurance consumed per drive. The line is nearly flat by nature — wear moves on a scale of weeks — so the useful reading is the spread between drives and the slope, not today's value. Joined to smartctl_device for the model name, because the device label alone is not comparable across nodes.",
+      "fieldConfig": {
+        "defaults": {
+          "color": {"mode": "palette-classic"},
+          "custom": {"axisCenteredZero": false, "axisColorMode": "text", "axisPlacement": "auto", "barAlignment": 0, "drawStyle": "line", "fillOpacity": 10, "gradientMode": "none", "hideFrom": {"legend": false, "tooltip": false, "viz": false}, "lineInterpolation": "smooth", "lineWidth": 2, "pointSize": 5, "scaleDistribution": {"type": "linear"}, "showPoints": "never", "spanNulls": false, "stacking": {"group": "A", "mode": "none"}, "thresholdsStyle": {"mode": "dashed"}},
+          "mappings": [],
+          "max": 100,
+          "min": 0,
+          "thresholds": {"mode": "absolute", "steps": [{"color": "green", "value": null}, {"color": "orange", "value": 80}, {"color": "red", "value": 95}]},
+          "unit": "percent"
+        },
+        "overrides": []
+      },
+      "gridPos": {"h": 9, "w": 12, "x": 0, "y": 13},
+      "id": 15,
+      "options": {"legend": {"calcs": ["last"], "displayMode": "table", "placement": "bottom", "showLegend": true}, "tooltip": {"mode": "multi", "sort": "desc"}},
+      "targets": [
+        {
+          "datasource": {"type": "prometheus", "uid": "prometheus"},
+          "expr": "smartctl_device_percentage_used * on (node, device) group_left(model_name) smartctl_device",
+          "legendFormat": "{{node}} {{model_name}}",
+          "refId": "A"
+        }
+      ],
+      "title": "NVMe wear",
+      "type": "timeseries"
+    },
+    {
+      "datasource": {"type": "prometheus", "uid": "prometheus"},
+      "description": "The failure-now signals, as opposed to the endurance budget above. Spare below its threshold means the drive has run out of blocks to remap defects into; media errors are unrecoverable data-integrity failures and should never increment; the critical warning is a bitfield the drive raises itself. Written bytes is the counter behind the wear percentage, useful for projecting when a drive will reach it.",
+      "fieldConfig": {
+        "defaults": {
+          "color": {"mode": "thresholds"},
+          "custom": {"align": "auto", "cellOptions": {"type": "auto"}, "inspect": false},
+          "mappings": [],
+          "thresholds": {"mode": "absolute", "steps": [{"color": "text", "value": null}]}
+        },
+        "overrides": [
+          {"matcher": {"id": "byName", "options": "wear"}, "properties": [{"id": "unit", "value": "percent"}, {"id": "custom.cellOptions", "value": {"type": "color-text"}}, {"id": "thresholds", "value": {"mode": "absolute", "steps": [{"color": "green", "value": null}, {"color": "orange", "value": 80}, {"color": "red", "value": 95}]}}]},
+          {"matcher": {"id": "byName", "options": "spare"}, "properties": [{"id": "unit", "value": "percent"}]},
+          {"matcher": {"id": "byName", "options": "media errors"}, "properties": [{"id": "custom.cellOptions", "value": {"type": "color-text"}}, {"id": "thresholds", "value": {"mode": "absolute", "steps": [{"color": "green", "value": null}, {"color": "red", "value": 1}]}}]},
+          {"matcher": {"id": "byName", "options": "critical warning"}, "properties": [{"id": "custom.cellOptions", "value": {"type": "color-text"}}, {"id": "thresholds", "value": {"mode": "absolute", "steps": [{"color": "green", "value": null}, {"color": "red", "value": 1}]}}]},
+          {"matcher": {"id": "byName", "options": "powered on"}, "properties": [{"id": "unit", "value": "s"}]},
+          {"matcher": {"id": "byName", "options": "written"}, "properties": [{"id": "unit", "value": "bytes"}]}
+        ]
+      },
+      "gridPos": {"h": 9, "w": 12, "x": 12, "y": 13},
+      "id": 16,
+      "options": {"cellHeight": "sm", "footer": {"countRows": false, "fields": "", "reducer": ["sum"], "show": false}, "showHeader": true, "sortBy": [{"desc": true, "displayName": "wear"}]},
+      "targets": [
+        {"datasource": {"type": "prometheus", "uid": "prometheus"}, "expr": "smartctl_device_percentage_used * on (node, device) group_left(model_name) smartctl_device", "format": "table", "instant": true, "refId": "A"},
+        {"datasource": {"type": "prometheus", "uid": "prometheus"}, "expr": "smartctl_device_available_spare * on (node, device) group_left(model_name) smartctl_device", "format": "table", "instant": true, "refId": "B"},
+        {"datasource": {"type": "prometheus", "uid": "prometheus"}, "expr": "smartctl_device_media_errors * on (node, device) group_left(model_name) smartctl_device", "format": "table", "instant": true, "refId": "C"},
+        {"datasource": {"type": "prometheus", "uid": "prometheus"}, "expr": "smartctl_device_critical_warning * on (node, device) group_left(model_name) smartctl_device", "format": "table", "instant": true, "refId": "D"},
+        {"datasource": {"type": "prometheus", "uid": "prometheus"}, "expr": "smartctl_device_power_on_seconds * on (node, device) group_left(model_name) smartctl_device", "format": "table", "instant": true, "refId": "E"},
+        {"datasource": {"type": "prometheus", "uid": "prometheus"}, "expr": "smartctl_device_bytes_written * on (node, device) group_left(model_name) smartctl_device", "format": "table", "instant": true, "refId": "F"}
+      ],
+      "title": "SMART health",
+      "transformations": [
+        {"id": "merge", "options": {}},
+        {
+          "id": "organize",
+          "options": {
+            "excludeByName": {"Time": true, "__name__": true, "container": true, "endpoint": true, "instance": true, "job": true, "namespace": true, "pod": true, "service": true},
+            "indexByName": {},
+            "renameByName": {"node": "node", "device": "device", "model_name": "model", "Value #A": "wear", "Value #B": "spare", "Value #C": "media errors", "Value #D": "critical warning", "Value #E": "powered on", "Value #F": "written"}
+          }
+        }
+      ],
+      "type": "table"
+    },
    {
      "datasource": {"type": "prometheus", "uid": "prometheus"},
      "description": "Read and write throughput per drive.",
@@ -141,7 +234,7 @@
        },
        "overrides": []
      },
-      "gridPos": {"h": 9, "w": 12, "x": 0, "y": 13},
+      "gridPos": {"h": 9, "w": 12, "x": 0, "y": 22},
      "id": 2,
      "options": {"legend": {"calcs": ["mean", "max"], "displayMode": "table", "placement": "bottom", "showLegend": true}, "tooltip": {"mode": "multi", "sort": "desc"}},
      "targets": [
@@ -174,7 +267,7 @@
        },
        "overrides": []
      },
-      "gridPos": {"h": 9, "w": 12, "x": 12, "y": 13},
+      "gridPos": {"h": 9, "w": 12, "x": 12, "y": 22},
      "id": 3,
      "options": {"legend": {"calcs": ["mean", "max"], "displayMode": "table", "placement": "bottom", "showLegend": true}, "tooltip": {"mode": "multi", "sort": "desc"}},
      "targets": [
@@ -207,7 +300,7 @@
        },
        "overrides": []
      },
-      "gridPos": {"h": 9, "w": 12, "x": 0, "y": 22},
+      "gridPos": {"h": 9, "w": 12, "x": 0, "y": 31},
      "id": 4,
      "options": {"legend": {"calcs": ["mean", "max"], "displayMode": "table", "placement": "bottom", "showLegend": true}, "tooltip": {"mode": "multi", "sort": "desc"}},
      "targets": [
@@ -245,7 +338,7 @@
          }
        ]
      },
-      "gridPos": {"h": 9, "w": 12, "x": 12, "y": 22},
+      "gridPos": {"h": 9, "w": 12, "x": 12, "y": 31},
      "id": 5,
      "options": {"legend": {"calcs": ["mean", "max"], "displayMode": "table", "placement": "bottom", "showLegend": true}, "tooltip": {"mode": "multi", "sort": "desc"}},
      "targets": [
@@ -278,7 +371,7 @@
        },
        "overrides": []
      },
-      "gridPos": {"h": 9, "w": 12, "x": 0, "y": 31},
+      "gridPos": {"h": 9, "w": 12, "x": 0, "y": 40},
      "id": 6,
      "options": {"legend": {"calcs": ["mean", "max"], "displayMode": "table", "placement": "bottom", "showLegend": true}, "tooltip": {"mode": "multi", "sort": "desc"}},
      "targets": [
@@ -305,7 +398,7 @@
        },
        "overrides": []
      },
-      "gridPos": {"h": 9, "w": 12, "x": 12, "y": 31},
+      "gridPos": {"h": 9, "w": 12, "x": 12, "y": 40},
      "id": 7,
      "options": {"legend": {"calcs": ["mean", "max"], "displayMode": "table", "placement": "bottom", "showLegend": true}, "tooltip": {"mode": "multi", "sort": "desc"}},
      "targets": [
@@ -340,7 +433,7 @@
        },
        "overrides": []
      },
-      "gridPos": {"h": 8, "w": 24, "x": 0, "y": 40},
+      "gridPos": {"h": 8, "w": 24, "x": 0, "y": 49},
      "id": 9,
      "options": {"legend": {"calcs": ["last", "max"], "displayMode": "table", "placement": "bottom", "showLegend": true}, "tooltip": {"mode": "multi", "sort": "desc"}},
      "targets": [
@@ -356,11 +449,11 @@
    },
    {
      "datasource": {"type": "prometheus", "uid": "prometheus"},
-      "gridPos": {"h": 11, "w": 24, "x": 0, "y": 48},
+      "gridPos": {"h": 11, "w": 24, "x": 0, "y": 57},
      "id": 8,
      "options": {
        "code": {"language": "plaintext", "showLineNumbers": false, "showMiniMap": false},
-        "content": "### What this dashboard cannot tell you\n\nThese notes are about mechanisms, not about the drives currently fitted. The inventory table above is the live answer to what is in the machines; nothing here restates it, because prose does not get re-read when hardware is swapped.\n\n**Endurance is missing.** No wear, no written-bytes total, no power-on hours, no media-error count — no exporter here produces them. NVMe reports those over an admin ioctl that needs elevated privileges; temperature is the only health value the kernel publishes through sysfs. Tracked as **#549**. Do not read a green top row as a healthy drive.\n\nCeph does record wear, but only inside its own devicehealth module and not in Prometheus: `kubectl -n rook-ceph exec deploy/rook-ceph-tools -- ceph device ls`. It covers OSDs and nothing else, and a drive removed from Ceph is purged from that registry — its history goes with it, so the wear figure of a retired drive is not recoverable after the fact.\n\n**Roles are assigned in configuration, not by device name.** Talos selects the system disk and the EPHEMERAL volume by serial, Rook selects the OSD by `/dev/disk/by-id` path. Two consequences outlive any particular set of drives: a broad selector such as `disk.transport == 'nvme'` matches every drive in the box, with the installer taking the OSD as the failure mode — and a drive retired from Ceph is not necessarily out of service, so the drive with the least endurance left can be the one carrying container state.\n\n**A dying NVMe here hangs rather than errors.** Talos boots with `nvme_core.io_timeout=4294967295`, so NVMe commands never time out. Expect a stall, not an I/O error, and expect the latency panel to go flat rather than spike.\n\n**Kernel messages are not retained.** Talos kernel logs do not reach Loki — the only log jobs are Kubernetes pods and a systemd-journal from elsewhere. `talosctl -n <node> dmesg` is the only source, it is a ring buffer, and a reboot empties it. An NVMe error from before the last reboot left no trace anywhere.",
+        "content": "### What this dashboard cannot tell you\n\nThese notes are about mechanisms, not about the drives currently fitted. The inventory table above is the live answer to what is in the machines; nothing here restates it, because prose does not get re-read when hardware is swapped.\n\n**Wear is a budget, not a prediction.** The percentage is what the drive reports against its own rated endurance. Drives do not stop at 100 — they usually keep working and start consuming spare blocks — so read it for planning, and read available spare and media errors for whether something is failing now. Those are different questions and the alert rules treat them as such.\n\n**A green top row is not a healthy drive.** Endurance says nothing about the drive that dies of a controller fault tomorrow, and this dashboard cannot see one coming.\n\nCeph keeps its own wear figures for OSDs in the devicehealth module, which is a useful cross-check but covers OSDs only: `kubectl -n rook-ceph exec deploy/rook-ceph-tools -- ceph device ls`. A drive removed from Ceph is purged from that registry and its history goes with it.\n\n**Roles are assigned in configuration, not by device name.** Talos selects the system disk and the EPHEMERAL volume by serial, Rook selects the OSD by `/dev/disk/by-id` path. Two consequences outlive any particular set of drives: a broad selector such as `disk.transport == 'nvme'` matches every drive in the box, with the installer taking the OSD as the failure mode — and a drive retired from Ceph is not necessarily out of service, and putting a worn one on EPHEMERAL is a sensible destination rather than a hazard — that volume is built to be rebuilt. Check the inventory table for what a given drive holds before reading its wear as urgent.\n\n**A dying NVMe here hangs rather than errors.** Talos boots with `nvme_core.io_timeout=4294967295`, so NVMe commands never time out. Expect a stall, not an I/O error, and expect the latency panel to go flat rather than spike.\n\n**Kernel messages are not retained.** Talos kernel logs do not reach Loki — the only log jobs are Kubernetes pods and a systemd-journal from elsewhere. `talosctl -n <node> dmesg` is the only source, it is a ring buffer, and a reboot empties it. An NVMe error from before the last reboot left no trace anywhere.",
        "mode": "markdown"
      },
      "title": "Gaps and caveats",
@@ -1,35 +1,8 @@
 # SMART/endurance metrics for every NVMe drive in the fleet (#549).
 #
-# WHY THIS HOLDS ELEVATED CAPABILITIES, and why that is a deliberate exception
-# rather than an oversight:
-#
-# NVMe reports health over an admin ioctl on the character device
-# (NVME_IOCTL_ADMIN_CMD), which the kernel gates on CAP_SYS_ADMIN. There is no
-# sysfs path for wear, media errors or written-bytes totals — hwmon publishes
-# the controller temperature and nothing else. Upstream smartctl_exporter
-# documents `privileged: true` and `user: root` for exactly this reason.
-#
-# The alternative that needs no privileges — reading Ceph's devicehealth
-# archive, which does hold full smartctl output — covers OSD drives only. In
-# this cluster that is three of nine, and the six it misses include the drives
-# that were retired from Ceph for wear and now carry EPHEMERAL. Covering the
-# healthy drives and not the worn ones was judged not worth a new service; the
-# owner chose fleet-wide coverage with the privilege exception instead.
-#
-# The exception is kept as small as the kernel allows: no `privileged: true`,
-# no host namespaces, no hostPID. Only CAP_SYS_ADMIN and CAP_SYS_RAWIO are
-# added, everything else is dropped, and the only host mount is /dev — which
-# is required because the exporter must open the NVMe character devices and
-# Kubernetes has no way to pass individual character devices to a pod without
-# a device plugin.
-#
-# If this ever needs revisiting: the thing to check is whether the kernel has
-# grown a sysfs interface for NVMe health, not whether some other exporter
-# needs fewer privileges. The requirement comes from the ioctl gate, not from
-# the tool.
-#
-# Upstream had no release between 2025-04-22 (v0.14.0) and this deployment.
-# The repository is not archived; the pin is simply its newest tag.
+# Runs privileged: host device access is gated by the container device cgroup,
+# and Kubernetes offers no per-device allowlist. Narrower settings do not work;
+# the alternatives that were tried are in the commit history.
 apiVersion: apps/v1
 kind: DaemonSet
 metadata:
@@ -55,10 +28,8 @@ spec:
      containers:
        - name: smartctl-exporter
          image: quay.io/prometheuscommunity/smartctl-exporter:v0.14.0
-          # No --smartctl.device on purpose: the exporter scans for devices
-          # itself and rescans every 10m by default. Device names are not
-          # stable across these machines, so a hardcoded list would quietly
-          # stop covering a drive the next time one is replaced.
+          # No --smartctl.device: the exporter scans and rescans on its own.
+          # Device names are not stable across these machines.
          args:
            - --web.listen-address=:9633
          ports:
@@ -66,42 +37,18 @@ spec:
              containerPort: 9633
              protocol: TCP
          securityContext:
-            # Root plus two capabilities, NOT privileged. See the header.
            runAsUser: 0
            runAsNonRoot: false
-            privileged: false
-            allowPrivilegeEscalation: false
+            privileged: true
+            # The API rejects privileged together with
+            # allowPrivilegeEscalation: false.
+            allowPrivilegeEscalation: true
            readOnlyRootFilesystem: true
-            capabilities:
-              drop: ["ALL"]
-              add: ["SYS_ADMIN", "SYS_RAWIO"]
-            # The capabilities alone are not enough, and this was measured
-            # rather than assumed. With the default profile the exporter found
-            # all three drives and could open none of them:
-            #   "Smartctl open device: /dev/nvme0 failed: Operation not
-            #   permitted"
-            # EPERM is the default seccomp action for a syscall the profile
-            # does not list. Reading /proc/1/status in the running container
-            # separated the two candidates: CapEff was 0x220000, so SYS_ADMIN
-            # and SYS_RAWIO were both effective — while Seccomp was 2 with one
-            # filter loaded. The kubelet sets seccompDefault: true, so every
-            # pod that does not say otherwise gets RuntimeDefault.
-            #
-            # This is still narrower than `privileged: true`, which would also
-            # grant every capability, all devices and write access to /sys.
-            # Narrowing further would mean shipping a custom seccomp profile
-            # that allows exactly the ioctl smartctl needs — worth doing if
-            # this list of exceptions ever grows, not worth it for one pod.
-            seccompProfile:
-              type: Unconfined
          volumeMounts:
+            # Not read-only: smartmontools opens NVMe devices read-write.
            - name: dev
              mountPath: /dev
-              readOnly: true
-            # smartctl is not known to need scratch space, but the root
-            # filesystem is read-only and a tool that turns out to want /tmp
-            # would crashloop instead of degrading. Cheaper to provide it than
-            # to find out from a restart counter.
+            # Scratch space, because the root filesystem is read-only.
            - name: tmp
              mountPath: /tmp
          resources:
@@ -1,18 +0,0 @@
-apiVersion: external-secrets.io/v1
-kind: ExternalSecret
-metadata:
-  name: barman-cloud-creds
-  namespace: paperless
-  annotations:
-    # Prune-disabled — a standing guard kept from the seed->paperless-KS handoff (barman creds).
-    kustomize.toolkit.fluxcd.io/prune: disabled
-spec:
-  refreshInterval: 1h
-  secretStoreRef:
-    kind: ClusterSecretStore
-    name: openbao
-  target:
-    name: barman-cloud-creds # keeps the old Secret's name — consumers unchanged
-  dataFrom:
-    - extract:
-        key: seed/paperless/barman-creds
@@ -1,3 +1,9 @@
+# One Hetzner S3 key, one path, shared by every barman ObjectStore. Separate
+# per-app paths would not make rotation independent — that needs one Hetzner
+# key per consumer (#397).
+#
+# velero reads the same key from infrastructure/velero-hetzner, which holds it
+# as a credentials file rather than these three fields.
 apiVersion: external-secrets.io/v1
 kind: ExternalSecret
 metadata:
@@ -15,4 +21,4 @@ spec:
    name: hetzner-s3-creds # keeps the old Secret's name — consumers unchanged
  dataFrom:
    - extract:
-        key: seed/paperless/hetzner-creds
+        key: infrastructure/hetzner-s3
@@ -20,7 +20,6 @@ resources:
  - cluster.yaml
  - objectstore.yaml
  - scheduled-backup.yaml
-  - barman-creds-externalsecret.yaml
  - hetzner-creds-externalsecret.yaml
  - pvcs.yaml
 configMapGenerator:
@@ -12,4 +12,4 @@ spec:
    name: hetzner-s3-creds
  dataFrom:
    - extract:
-        key: seed/trmnl/hetzner-creds
+        key: infrastructure/hetzner-s3
@@ -1,11 +1,8 @@
 ---
 # Barman S3 credentials for wp-pg.
 #
-# Sourced from seed/paperless/hetzner-creds, which is not where they belong.
-# Issue #397 wants woodpecker to own seed/woodpecker/hetzner-creds; creating
-# that path needs OpenBao write access (`bao kv list seed` → 403 for the
-# identities available here), so it stays open. The values are identical, so it
-# is a one-line swap of the `key:` below once the path exists.
+# One shared path for one shared credential — see the note in
+# ../paperless/hetzner-creds-externalsecret.yaml.
 #
 # The namespace allowlist on the openbao ClusterSecretStore
 # (infrastructure/post-crds/openbao-clustersecretstore.yaml) must include this
@@ -24,4 +21,4 @@ spec:
    name: hetzner-s3-creds
  dataFrom:
    - extract:
-        key: seed/paperless/hetzner-creds
+        key: infrastructure/hetzner-s3
@@ -36,11 +36,9 @@ spec:
  target:
    name: hetzner-s3-creds
  dataFrom:
-    # Reuses the paperless copy of the shared Hetzner S3 credentials (identical
-    # ACCESS_KEY_ID / ACCESS_SECRET_KEY / REGION) to avoid seeding a new OpenBao
-    # path for this migration — same approach woodpecker took. FOLLOW-UP: give
-    # wordpress its own seed/wordpress/hetzner-creds path once OpenBao can be
-    # written, and repoint this here (the value is the same, so it's a drop-in
-    # swap).
+    # One shared path for one shared credential. There is a single Hetzner S3
+    # key behind all of these — see the note in
+    # ../paperless/hetzner-creds-externalsecret.yaml for why per-app paths were
+    # the wrong shape and what would have to change for them to be right.
    - extract:
-        key: seed/paperless/hetzner-creds
+        key: infrastructure/hetzner-s3
@@ -1,27 +1,16 @@
 ---
 # Velero Schedules for stateful app namespaces.
 #
-# Scope is restricted to PersistentVolumeClaims via includedResources.
-# Flux owns every other K8s object (Deployment, Service, Ingress,
-# ConfigMap, Secret, …) — backing those up shadows current git state
-# on a rebuild: Velero restores stale manifests from yesterday's
-# snapshot, then the app Kustomization clobbers them with whatever git
-# says — except when the Kustomization is blocked on the restore chain,
-# leaving the cluster temporarily serving the stale spec (e.g. the
-# paperless Ingress missing prod hostnames after the 2026-04-22
-# rebuild). PVC-only is the canonical "back up data, not state" scope
-# (see ~/Notes/wiki/k8s-backup-scope.md and the project memory rule).
+# Scope is PersistentVolumeClaims only. Flux owns every other object, and
+# backing those up shadows git on a rebuild: Velero restores yesterday's
+# manifests and the cluster serves them until the Kustomization catches up.
+# Back up data, not state.
 #
-# snapshotMoveData=true keeps doing the heavy lifting via Kopia +
-# node-agent: PVC contents are uploaded to Garage and restored
+# snapshotMoveData uploads PVC contents through Kopia and the node-agent,
 # independently of the K8s API surface.
 #
-# Naming convention: <app>-daily for the app's Schedule. Restore is a
-# manual, operator-driven procedure — see kubernetes/RUNBOOK-cold-rebuild.md.
-# (There is no automatic bootstrap-restore Job; it was removed as dead code,
-# issue #200.)
-#
-# Retention: 30 days, matching the live CNPG Barman ObjectStore policy.
+# Naming: <app>-daily. Restore is manual — see RUNBOOK-cold-rebuild.md.
+# Retention matches the CNPG Barman policy.

 apiVersion: velero.io/v1
 kind: Schedule
@@ -203,22 +192,13 @@ metadata:
  labels:
    app.kubernetes.io/part-of: homelab-backup
 spec:
-  # Daily at 06:45 local (next free stagger slot). The app PVCs live in
-  # the home-assistant namespace regardless of which app/ dir owns
-  # their manifest (matter-server, otbr, whisper, speech-to-phrase,
-  # zone-configurator all set `namespace: home-assistant` via their
-  # Kustomization, not per-resource): home-assistant-config (.storage
-  # entity registry, recorder DB, secrets.yaml), esphome-data,
-  # shelly-manager-data, matter-server-data, otbr-data, whisper-data,
-  # speech-to-phrase-models, speech-to-phrase-train, zigbee2mqtt-data,
-  # zwavejs-store, zone-configurator-config. On restore,
-  # home-assistant-config has its
-  # own path (the HA pod's `seed` initContainer pulling the native HAOS
-  # backup from Garage, see the home-assistant Kustomization comment in
-  # kubernetes/clusters/homelab/home-assistant.yaml); layering a Velero
-  # PVC restore on top of that flow for the same PVC needs its own review.
-  # Restore of these schedules is manual — see
-  # kubernetes/RUNBOOK-cold-rebuild.md.
+  # Daily at 06:45 local. Sweeps every PVC in the home-assistant namespace —
+  # several apps under apps/ set `namespace: home-assistant` in their
+  # Kustomization, so their PVCs land here too.
+  #
+  # home-assistant-config has its own restore path: the HA pod's `seed`
+  # initContainer pulls the native HAOS backup. Layering a Velero PVC restore
+  # on top of that for the same PVC needs its own review.
  schedule: "45 6 * * *"
  useOwnerReferencesInBackup: false
  template:
@@ -229,16 +209,9 @@ spec:
    storageLocation: default
    ttl: 720h0m0s
    snapshotMoveData: true
-    # The ha-pg CNPG cluster now runs in this namespace (it did not when
-    # this schedule was written — the old comment here still claimed
-    # "no CNPG cluster in this namespace"). Its PVC ha-pg-1 carries the
-    # cnpg.io/cluster label and was being swept in: a crash-consistent
-    # snapshot of a running Postgres data directory is not a restorable
-    # backup, the same trap the wordpress-daily comment below describes.
-    # ha-pg is covered by Barman — daily base backup at 02:50 UTC
-    # (kubernetes/apps/home-assistant/ha-pg-scheduled-backup.yaml) plus
-    # continuous WAL archiving — so this exclusion removes a redundant
-    # 20 GiB upload, matching paperless/authentik/immich/trmnl above.
+    # Excludes the CNPG cluster's PVC. A crash-consistent snapshot of a
+    # running Postgres data directory is not a restorable backup, and Barman
+    # covers that database anyway — see ha-pg-scheduled-backup.yaml.
    labelSelector:
      matchExpressions:
        - key: cnpg.io/cluster
@@ -8,16 +8,9 @@ spec:
    image: quay.io/ceph/ceph:v19.2.6 # {"$imagepolicy": "flux-system:ceph"}
    allowUnsupported: false
  dataDirHostPath: /var/lib/rook
-  # Do not start restarting OSDs while PGs are still recovering. The default
-  # is false, so Rook would proceed regardless — and paired with the old
-  # osdMaxUpdatesInParallel default that means it can take the next OSD down
-  # while the previous one's data is still being caught up.
-  #
-  # With three OSDs and size 3 there is no spare copy to fall back on: the
-  # gate between one OSD returning and the next going down is the only thing
-  # that keeps a rolling change from becoming an outage. See
-  # storage.osdMaxUpdatesInParallel below, which bounds the same operation
-  # from the other side.
+  # Defaults to false. With three OSDs and size 3 there is no spare copy, so
+  # this gate is the only thing keeping a rolling OSD change from taking the
+  # next one down mid-recovery. Paired with storage.osdMaxUpdatesInParallel.
  upgradeOSDRequiresHealthyPGs: true
  mon:
    count: 3
@@ -39,113 +32,40 @@ spec:
      daemon:
        keyRotationPolicy: KeyGeneration
        keyGeneration: 2
-  # Bump CephFS subvolume cloner pool from 4 → 16. Velero CSI Snapshot
-  # Data Movement provisions a backupPVC per source PVC by cloning the
-  # VolumeSnapshot, and a 4-thread default stalls migrate-immich's
-  # multi-PVC Backup with `rados: "all cloner threads are busy"`. 16
-  # gives headroom for parallel restores during cluster rebuild too
-  # (paperless + audiobookshelf + immich + ... all clone at once).
+  # CephFS cloner pool raised from the default 4. Velero clones a
+  # VolumeSnapshot per PVC, and 4 threads stall a multi-PVC backup with
+  # `rados: "all cloner threads are busy"`.
  cephConfig:
    mon:
-      # The Ceph default, stated rather than left out. Removing the line would
-      # not restore it: `ceph config` keeps a value that only disappears from
-      # this file, so the old 20 would sit in the mon config database
-      # indefinitely — the same trap the bluestore settings below describe,
-      # and the one that crash-looped an OSD during the network provider
-      # change when public_network survived being deleted here.
-      #
-      # It was 20 because the mons share the node's /var with containerd, and
-      # on the VMs that was ~60 GB: 30% free measured image and snapshot churn
-      # rather than anything about Ceph, so k8s-2 tripped MON_DISK_LOW whenever
-      # the image cache filled and GC could not reclaim it (#434).
-      #
-      # Bare metal removed the premise. /var is now ~931 GB per node at 7-8%
-      # used, so 30% free is a real reserve again and the ~106 MB mon database
-      # is irrelevant against it. Reaching 70% would be a genuine signal about
-      # the node rather than noise about the image cache.
-      #
-      # mon_data_avail_crit stays at the 5% default, and CephMonDiskLow in
-      # monitoring-rules still watches /var directly for the real risk, which
-      # is the node filling rather than the mon growing.
+      # The Ceph default, stated rather than omitted. Deleting a line here does
+      # NOT restore the default: `ceph config` keeps whatever was last applied,
+      # so the old value would sit in the mon config database indefinitely.
+      # Change values in place; to actually drop one, `ceph config rm` it.
      mon_data_avail_warn: "30"
-      # Stop compacting the whole RocksDB prefix on every paxos trim.
+      # Off, against the upstream default. The forced compact_range on every
+      # paxos trim rewrote the whole store hundreds of times a day and was the
+      # single largest source of disk writes on these nodes.
      #
-      # Upstream default is true — "Compact a certain prefix (including paxos)
-      # when we trim its old states" — which is fine at low paxos rates and
-      # pathological here. Measured 2026-08-19:
-      #
-      #   paxos transactions      ~99,000/day  (1.15/s, sampled over 60 s)
-      #   paxos logical data       811 MB/day  (21.9 GB over 27 d uptime)
-      #   ACTUAL mon disk writes    80 GB/day  per mon, 240 GB/day for three
-      #                                        (cgroup io.stat: 2.15 TB/27 d)
-      #   => ~98x write amplification, for a ~106 MB database
-      #
-      # That was ~62% of all OS-disk writes on these nodes and roughly a
-      # quarter of everything the cluster writes — more than every client
-      # workload combined. With paxos_trim_min at 250, ~99k transactions/day
-      # means hundreds of forced range compactions per day, each rewriting the
-      # store.
-      #
-      # The churn itself is 99% cluster log and mgr stats, not real cluster
-      # activity: logm holds 6.7M paxos versions and mgrstat 4.4M, against
-      # osdmap's 9.6k. Every Rook-operator poll (mgr stat / versions / status /
-      # report / osd dump — 23 audit entries per minute per mon) becomes a
-      # cluster-log entry, hence a paxos transaction, replicated to all three
-      # mons. Reducing that polling is the complementary fix and is tracked
-      # separately; this setting removes the amplification regardless of rate.
-      #
-      # This does NOT disable compaction. RocksDB's own levelled compaction
-      # still runs and still reclaims trimmed keys; what stops is the extra
-      # forced compact_range on every trim. Store growth is therefore bounded
-      # by normal compaction, and there are two backstops if that assumption is
-      # wrong: mon_data_size_warn (15 GB default) raises HEALTH_WARN, which
-      # CephHealthWarn in monitoring-rules already alerts on, and
-      # mon_compact_on_start below compacts fully on every mon restart.
-      #
-      # Watch after applying: `du -sh /var/lib/rook/mon-*/store.db` on a node,
-      # or the mon store size in `ceph status`. If it grows past ~1 GB and does
-      # not come back down, revisit rather than leaving it.
+      # This does NOT disable compaction — RocksDB's levelled compaction still
+      # reclaims trimmed keys. Backstops if that proves wrong:
+      # mon_data_size_warn raises HEALTH_WARN, and mon_compact_on_start below
+      # compacts fully on every mon restart.
      mon_compact_on_trim: "false"
-      # Compensating control for the above: a full compaction on mon start.
-      # Upstream default is false. Mons restart on upgrades, node reboots and
-      # reschedules, so this gives a periodic full reclaim without paying for
-      # one on every trim. Cheap here — the store is ~106 MB.
+      # Compensating control, against the upstream default: mons restart often
+      # enough for this to give periodic full reclaim without paying for one
+      # on every trim.
      mon_compact_on_start: "true"
    mgr:
      mgr/volumes/max_concurrent_clones: "16"
-    # Discard/TRIM for the QLC NVMe per host (CT1000P3PSSD8, Crucial P3 Plus —
-    # earlier comments here said "P2", which is a different drive). These need
-    # an OSD restart to take effect (init-time). Baseline 2026-05-05:
-    # 71.6 MB/s avg / 0.89 s avg latency on a 5-min replicated 4 MiB write
-    # bench (post-SLC-cache). See ceph-speed-baseline-2026-05-05 in the wiki.
+    # Discard/TRIM. Init-time settings — an OSD restart is needed to apply.
    #
-    # bluestore_prefer_deferred_size_ssd / bluestore_deferred_batch_ops_ssd are
-    # DELIBERATELY LEFT AT THE CEPH DEFAULTS (0 and 16) and must not be raised
-    # again without re-reading this.
-    #
-    # They were previously set to the HDD-style 65536 / 64 as a throughput tune.
-    # prefer_deferred_size defers every write SMALLER than the threshold: the
-    # write goes first into RocksDB's WAL and is applied to the object store
-    # afterwards. That is a double write, and at 65536 it caught essentially
-    # every write this cluster makes — SQLite pages are 4 KiB, Postgres pages
-    # 8 KiB. Ceph disables deferral on SSD (default 0) precisely because solid
-    # state does not need the random-write batching that helps spinning rust.
-    #
-    # Two reasons it was the wrong trade here:
-    #   - The benchmark that justified it cannot have exercised it. It used
-    #     4 MiB writes, 64x ABOVE the 64 KiB cutoff, so not one of those writes
-    #     was ever deferred. The setting was validated by a workload it does
-    #     not affect.
-    #   - It doubles writes onto QLC, which has the lowest endurance of any
-    #     NAND type. Measured 2026-08-19: all three OSD drives at 80/82/87%
-    #     endurance used, advancing ~0.13 points/day, i.e. rated life exhausted
-    #     between Nov 2026 and Jan 2027 — and simultaneously, since size=3 on
-    #     3 OSDs means every drive absorbs 100% of cluster writes (see #434).
-    #
-    # This cluster is write-light (~117 GB/day at the RBD client layer), so
-    # throughput was never the binding constraint. Endurance is. If small-write
-    # latency ever becomes the real problem, fix it with more OSDs rather than
-    # by paying a 2x write tax on every 4 KiB page.
+    # bluestore_prefer_deferred_size_ssd and bluestore_deferred_batch_ops_ssd
+    # are DELIBERATELY LEFT AT THE CEPH DEFAULTS and must not be raised again.
+    # Deferral double-writes everything below the threshold, and an HDD-style
+    # value catches every write this cluster makes (4 KiB SQLite, 8 KiB
+    # Postgres pages). Ceph disables it on SSD for that reason. Throughput has
+    # never been the binding constraint here; endurance is. If small-write
+    # latency becomes a real problem, add OSDs instead.
    osd:
      bdev_enable_discard: "true"
      bdev_async_discard: "true"
@@ -159,106 +79,44 @@ spec:
    ssl: false
  monitoring:
    enabled: true
-  # Dedicated Ceph cluster network on VLAN 49, carried by the second X710
-  # SFP+ port (enp2s0f1np1) on each node, attached to the OSDs through Multus.
+  # Dedicated Ceph cluster network on VLAN 49, attached to the OSDs through
+  # Multus. The attachment is san-network-attachment.yaml.
  #
-  # WHY NOT provider: host, WHICH ALSO REACHES THAT LINK
+  # Only `cluster` is selected. Do not add `public`, and do not reach for
+  # `addressRanges` — that is honoured only under provider: host, which puts
+  # every daemon including the mons on host networking. A mon's address then
+  # becomes the node's DHCP lease, and when a lease moves the mon crash-loops
+  # on "Cannot assign requested address" with no node free to fail over to,
+  # because all three already hold the mon host ports.
  #
-  # Because it reaches it for every daemon, not just the ones that need it.
-  # The cluster network is an OSD concern: per the Ceph documentation it
-  # carries OSD heartbeat, replication and recovery, and "Ceph Monitors always
-  # operate on the public network". `addressRanges` is only honoured under
-  # provider: host, so using it put the mons on host networking as a side
-  # effect — making a mon's address the node's DHCP lease.
+  # With `public` unset, client traffic stays on the pod network and VLAN 49
+  # carries Ceph-internal traffic only — which is also why Rook's Multus
+  # prerequisites about host routing do not apply here.
  #
-  # That is not theoretical. When a lease moved, the mon could no longer bind
-  # ("Cannot assign requested address") and crash-looped. Rook detected it and
-  # started a failover, but with three mons on three nodes each holding the
-  # mon host ports, the replacement could not be scheduled anywhere — the
-  # canary sat Pending on "didn't have free ports". Two of three nodes hit
-  # this during the Talos v1.12.11 upgrade and both needed hand intervention.
-  #
-  # Only `cluster` is selected here. With `public` left unset Rook puts client
-  # traffic on the pod network, so mons, MDS, MGR and the CSI pods keep
-  # Rook-managed identities and hold no host ports — which is what removes
-  # that failure mode rather than working around it.
-  #
-  # ISOLATION IS PRESERVED
-  #
-  # Rook's Multus prerequisites about hosts routing to the Multus network
-  # apply to a Multus *public* network. Selecting only `cluster` means they do
-  # not apply, so VLAN 49 stays what it is: Ceph-internal traffic and nothing
-  # else, no router, no other participants. After this settles, the node
-  # addresses on that segment (10.99.0.1-.3) have no remaining purpose and
-  # should come out of the Talos configs — at which point the attachment's
-  # pool can take the whole /29.
-  #
-  # Reached from provider: "" rather than directly from host, which Rook's CRD
-  # rejects. See the phase A commit.
-  #
-  # ONE-TIME STEP THAT THIS FILE CANNOT EXPRESS, recorded because it is not
-  # reproducible from the manifests alone. Removing addressRanges here does
-  # not clear public_network and cluster_network from Ceph's own config
-  # database — the same trap the bluestore comment above describes: `ceph
-  # config` retains a value that is only deleted from this file. During the
-  # phase A rollout the first OSD came up on the pod network, still had
-  # public_network 10.2.40.0/24 in the config database, found no interface in
-  # it and crash-looped on "Failed to pick public address". Both keys were
-  # removed with `ceph config rm global public_network` and the same for
-  # cluster_network; Rook then wrote cluster_network afresh from the
-  # attachment below. Anyone rebuilding this cluster from scratch will not hit
-  # it — the config database starts empty — but anyone repeating a provider
-  # change on a live cluster will.
-  #
-  # Bounded by upgradeOSDRequiresHealthyPGs and storage.osdMaxUpdatesInParallel
-  # above: one OSD restarts at a time and only once PGs are clean again.
-  #
-  # The attachment itself is san-network-attachment.yaml.
+  # Changing the provider on a LIVE cluster needs a step this file cannot
+  # express: `ceph config` retains public_network and cluster_network after
+  # they disappear from here, and an OSD that comes up on the pod network with
+  # a stale public_network crash-loops on "Failed to pick public address".
+  # Clear them with `ceph config rm global public_network` (and cluster_network)
+  # before the rollout. A cluster built from scratch starts with an empty
+  # config database and never sees this.
  network:
    provider: multus
    selectors:
      cluster: rook-ceph/ceph-san
-  # Nodes are listed explicitly rather than useAllNodes, so that a node can be
-  # taken out of the storage fleet by removing it here. Under useAllNodes the
-  # operator re-provisions an OSD on any node whose device still carries a
-  # BlueStore signature, which makes purging an OSD ahead of pulling its drive
-  # impossible: the OSD is recreated within a reconcile and starts backfilling
-  # onto the drive being replaced.
+  # Nodes listed explicitly, not useAllNodes: under useAllNodes the operator
+  # re-provisions an OSD on any node whose device still carries a BlueStore
+  # signature, so purging an OSD before pulling its drive is impossible — it
+  # comes back within a reconcile and backfills onto the drive being replaced.
  #
-  # All three nodes are bare metal and see three NVMe drives each, so they name
-  # their OSDs by /dev/disk/by-id path. A bare name would be actively wrong:
-  # Talos enumerates these machines' drives in a different order than Proxmox
-  # did, and the kernel name lands on the Kingston SYSTEM disk or on EPHEMERAL
-  # depending on the boot. Rook would probably decline the system disk for
-  # carrying partitions, but that is luck rather than intent. The by-id path is
-  # derived from model and serial and does not depend on enumeration at all.
-  #
-  # k8s-3 demonstrated why: it enumerated the Kingston as nvme0n1 on one boot
-  # and the Crucial as nvme0n1 on the very next one.
-  #
-  #   k8s-1 (jupiter)
-  #   50026B7382B48B86  Kingston  — Talos system disk
-  #   2332E86B749A      Crucial   — Talos EPHEMERAL (/var)
-  #   S437NX0M400426    PM983     — this OSD
-  #
-  #   k8s-2 (saturn)
-  #   50026B7382DA5F6E  Kingston  — Talos system disk
-  #   2332E86B74BC      Crucial   — Talos EPHEMERAL (/var)
-  #   S437NX0M403161    PM983     — this OSD
-  #
-  #   k8s-3 (neptune)
-  #   50026B7382B48B90  Kingston  — Talos system disk
-  #   2326E6E8E67D      Crucial   — Talos EPHEMERAL (/var)
-  #   S437NF0M501176    PM983     — this OSD
+  # Devices are named by /dev/disk/by-id path. Kernel names are not stable
+  # across boots on these machines — k8s-3 enumerated a different drive as
+  # nvme0n1 on two consecutive boots — and a bare name can land on the system
+  # disk or on EPHEMERAL.
  storage:
-    # One OSD restarted at a time. The default is 20, which on a three-OSD
-    # cluster means all of them at once — every PG inactive, every pool
-    # unreachable, for as long as the restart takes. The default suits a
-    # cluster large enough that 20 OSDs is a small fraction of it; here it is
-    # the whole thing.
-    #
-    # This binds any change that rewrites the OSD deployment spec, not just
-    # Ceph version upgrades — a network provider change is one such.
+    # One at a time. The default of 20 would restart every OSD in this cluster
+    # simultaneously — every PG inactive until they return. Binds any change
+    # that rewrites the OSD deployment spec, not just version upgrades.
    osdMaxUpdatesInParallel: 1
    useAllNodes: false
    useAllDevices: false
@@ -274,18 +132,12 @@ spec:
          - fullpath: /dev/disk/by-id/nvme-SAMSUNG_MZQLB960HAJR-00007_S437NF0M501176
    config:
      osdsPerDevice: "1"
-  # Storage layer must never be evicted by kubelet under node pressure
-  # and must never be picked first by the Linux OOM killer. system-node-
-  # critical (PriorityValue 2000001000) is the highest built-in class:
-  # kubelet preserves these pods last, and kernel sets oom_score_adj to
-  # -997 so anything else dies before a Ceph daemon does.
+  # Highest built-in class: kubelet evicts these last and the kernel gives
+  # them the lowest oom_score_adj.
  priorityClassNames:
    all: system-node-critical
-  # memory requests == limits => Guaranteed QoS. Combined with the
-  # priority class above, the pod's oom_score_adj is the lowest possible.
-  # CPU limits are deliberately NOT set — Ceph daemons benefit from
-  # bursting under recovery/backfill, and a CPU limit would throttle
-  # them; CPU pressure on this cluster is not a real concern (~15%).
+  # requests == limits gives Guaranteed QoS. CPU limits are deliberately NOT
+  # set — Ceph daemons burst during recovery and a limit would throttle them.
  resources:
    mon:
      requests:
@@ -5,52 +5,24 @@ machine:
    - k8s-3.srv.renner.uno
    - k8s.renner.uno
    - 10.2.40.60
-  # Install from the Image Factory metal installer, not the stock
-  # ghcr.io/siderolabs/installer that `talosctl gen config` defaults to.
-  # Extensions live in the installer image, so with the stock one the schematic
-  # is only ever a property of the boot media and nothing lands on disk —
-  # `talosctl get extensions` returns empty on a node installed that way.
+  # Image Factory metal installer, NOT the stock ghcr.io/siderolabs/installer
+  # that `talosctl gen config` defaults to. Extensions live in the installer
+  # image; install with the stock one and nothing lands on disk —
+  # `talosctl get extensions` comes back empty.
  #
-  # What the schematic carries, and why each matters here:
+  # The schematic carries intel-ucode, thunderbolt and i915, and sets
+  # net.ifnames=1, which is what the per-node VLAN parents match against.
+  # Changing which extensions are present means a new schematic hash and a
+  # reinstall or upgrade, not an edit here.
  #
-  #   siderolabs/intel-ucode   CPU microcode. On a VM the hypervisor supplied
-  #                            it; on bare metal nothing does except the BIOS.
-  #   siderolabs/thunderbolt   Inert until machine.kernel.modules asks for
-  #                            thunderbolt/thunderbolt_net. Present so enabling
-  #                            the MS-01 mesh later needs neither a new image
-  #                            nor a reinstall — which is exactly the property
-  #                            lost by installing without it.
-  #   siderolabs/i915          Intel GPU microcode and kernel modules for the
-  #                            Alder Lake-P Iris Xe in the MS-01. No workload
-  #                            requests /dev/dri today; it is here for the same
-  #                            reason as thunderbolt, so that wanting hardware
-  #                            transcoding later is a config change rather than
-  #                            another rolling upgrade of every node.
+  # Read only at install and upgrade time — editing this does nothing to a
+  # running node. The tag must match the version being upgraded to, or the
+  # upgrade is a downgrade. Talos only tests migration between adjacent minor
+  # releases: take the latest patch of each intermediate minor rather than
+  # skipping one.
  #
-  # Not included, and why, so the absences are not mistaken for oversights:
-  # the X710 (i40e) and I226 (igc) NICs need no firmware extension —
-  # intel-ice-firmware covers E810/ice only. mei is a prerequisite for Intel
-  # Arc discrete GPUs, of which there are none. iscsi-tools, nvme-cli and
-  # util-linux-tools have no consumer: storage is Ceph RBD, and device health
-  # is reported by Ceph itself rather than a node-level exporter.
-  #
-  # 0f6fb8bd… is the bare-metal schematic: same net.ifnames=1 as the Proxmox
-  # one (the predictable interface names the per-node VLAN parents match
-  # against), minus qemu-guest-agent. It supersedes a21cec8f…, which was
-  # identical but without i915 — see RUNBOOK-cold-rebuild.md.
-  #
-  # Only read at install and upgrade time. Changing it here does nothing to a
-  # running node until that node is upgraded. Bump the tag with the Talos
-  # version — it must match the running version, or the upgrade is a downgrade.
-  #
-  # Upgrades follow the documented path: migration is only tested between
-  # adjacent minor releases, so go to the latest patch of each intermediate
-  # minor rather than skipping. 1.12.11 -> 1.13.9 satisfies that — one minor
-  # step from the last 1.12 patch, no intermediate needed.
-  #
-  # Kubernetes is a separate decision and is not forced by this. Talos 1.13
-  # supports Kubernetes 1.36, 1.35, 1.34, 1.33, 1.32 and 1.31, so the cluster
-  # stays on 1.35.2 until `talosctl upgrade-k8s` moves it deliberately.
+  # The Kubernetes version is a separate decision, moved by
+  # `talosctl upgrade-k8s`.
  install:
    image: factory.talos.dev/metal-installer/0f6fb8bd8bb53013e9743b7c7b099d96fb9c32fd2464ced32693c2dc0ea5feb9:v1.13.9
  features:
@@ -74,20 +46,13 @@ machine:
    nodeIP:
      validSubnets:
        - 10.2.40.0/24
-    # Lower the image GC thresholds from the kubelet defaults (85/80) to
-    # bound containerd's image cache, which is the largest single consumer
-    # of /var. Spegel P2P pull-through softens the re-pull cost when GC'd
-    # images are needed back.
+    # Lower than the kubelet defaults (85/80) to bound containerd's image
+    # cache, the largest single consumer of /var.
    #
-    # These thresholds do NOT control whether Ceph's mon reports
-    # MON_DISK_LOW, and must not be tuned for that. Measured on k8s-2:
-    # image GC frees only the content store (~8.6 GB), while the bulk of
-    # /var/lib/containerd is ~20 GB of overlayfs snapshots — unpacked
-    # layers shared with running containers, which GC cannot reclaim.
-    # Dropping high to 60 deleted 28 images and moved free space by 0.02
-    # percentage points. The mon's own data is ~106 MB; its 30%-free
-    # warning is measuring a filesystem it merely shares, so the lever for
-    # it is elsewhere (mon volume, /var size, or mon_data_avail_warn).
+    # Do NOT tune these to clear Ceph's MON_DISK_LOW. Image GC reclaims only
+    # the content store; the bulk of /var/lib/containerd is overlayfs
+    # snapshots shared with running containers, which GC cannot touch. The
+    # lever for the mon warning is elsewhere.
    extraConfig:
      imageGCHighThresholdPercent: 70
      imageGCLowThresholdPercent: 60
@@ -1,55 +1,25 @@
-# k8s-1 runs Talos directly on jupiter's MS-01 hardware; k8s-2 and k8s-3 are
-# still Proxmox VMs. Every machine-specific selector below differs from theirs
-# for that reason: there are no virtio NICs, no PCI-passthrough layer, and all
-# four physical NICs and all three NVMe drives are visible to Talos at once.
-#
-# Networking uses the v1.12 multi-document config rather than the deprecated
-# machine.network.interfaces. That is deliberate: the docs do not define what
-# happens when the same link is configured by both schemas, so this file keeps
-# every link in one schema instead of straddling them.
+# Networking uses the multi-document config, not the deprecated
+# machine.network.interfaces. Keep every link in one schema: the docs do not
+# define what happens when both configure the same link.
 machine:
  network:
    hostname: k8s-1
  sysctls:
-    # ens19 (VLAN 30, v30iot) is LINK ONLY — no host addressing. It exists as
-    # the macvlan parent for the v30iot pod attachments
-    # (matter/otbr/shelly-manager/music-assistant), whose children do their own
-    # DHCP on that L2. Host addresses were never needed and are actively
-    # harmful: a connected 10.2.30.0/24 route makes node replies to IoT-subnet
-    # clients bypass the UDM, which breaks every UDM-DNATed flow (hairpin NAT:
-    # un-translated SYN-ACK -> client kernel RST, verified live 2026-07-23).
-    # This disables v6 entirely on that link, including link-local.
+    # ens19 (VLAN 30, v30iot) is LINK ONLY — it is the macvlan parent for the
+    # v30iot pod attachments and must never get host addressing. A connected
+    # 10.2.30.0/24 route makes node replies bypass the UDM and breaks every
+    # DNATed flow.
    net.ipv6.conf.ens19.disable_ipv6: "1"
-    # Same argument, applied to the physical ports rather than a VLAN child.
-    #
-    # enp2s0f0np0 is nothing but the trunk parent for mgmt0 and ens19, and
-    # enp87s0 is unused. Both sit on the untagged fallback network, where by
-    # design nothing is supposed to run — and both were autoconfiguring
-    # themselves from its router advertisements: an fd00::/64 ULA each, plus
-    # an IPv6 default route each.
-    #
-    # The result was four IPv6 default routes per node at identical priority
-    # 1024 — mgmt0, enp2s0f0np0, enp87s0 and lo — of which only mgmt0 has a
-    # globally routable source address. With nothing to break the tie,
-    # outbound IPv6 mostly left through an interface whose only usable source
-    # was a ULA, so the cluster had no IPv6 egress at all while IPv4 worked
-    # normally. It surfaced as two NetBird probes reporting the proxies down
-    # for 30 hours; the proxies were fine and answered IPv6 in 13 ms from
-    # outside.
-    #
-    # Verified on k8s-1 before rolling to the others: disabling v6 on a VLAN
-    # parent leaves the VLAN child alone. mgmt0 kept its global address and
-    # its fd40:: address, Ceph did not notice, and every failing probe
-    # recovered on the next scrape.
+    # These two sit on the untagged fallback network, where nothing may run.
+    # Left enabled they autoconfigure a ULA and an IPv6 default route from its
+    # RAs, which ties with mgmt0's and costs the cluster IPv6 egress.
+    # Disabling v6 on a VLAN parent does not affect the VLAN child.
    net.ipv6.conf.enp2s0f0np0.disable_ipv6: "1"
    net.ipv6.conf.enp87s0.disable_ipv6: "1"
  install:
-    # Three NVMe drives are ordinary block devices to Talos here: the Kingston
-    # OM8PGP41024Q-A0 system disk, the Samsung PM983 that Rook claims as the
-    # Ceph OSD, and the retired Crucial P3 that carries EPHEMERAL (see the
-    # VolumeConfig below). Every one of them is selected by serial. Nothing in
-    # this file may use a broad selector: `disk.transport == 'nvme'` matches all
-    # three, and the failure mode is Talos taking the OSD drive.
+    # Select disks by serial only. A broad selector such as
+    # `disk.transport == 'nvme'` matches every drive in the machine, and the
+    # failure mode is the installer taking the Ceph OSD drive.
    diskSelector:
      serial: 50026B7382B48B86
  certSANs:
@@ -59,15 +29,10 @@ machine:
 cluster:
  allowSchedulingOnControlPlanes: true
 ---
-# EPHEMERAL (/var) goes on the retired Crucial P3, not the system disk.
-#
-# That drive is at 87% of its rated endurance and was this node's Ceph OSD until
-# the PM983 replaced it. /var is exactly the right role for a disk in that
-# state: containerd's image and snapshot store, pod logs and the Ceph mon store
-# are all reconstructible, so the drive is consumable here in a way it is not as
-# an OSD. It also gives /var ~931 GB instead of the 64 GB the VM-era zvol had,
-# which is the constraint that makes k8s-2 and k8s-3 trip DiskPressure whenever
-# they absorb another node's pods.
+# EPHEMERAL (/var) goes on the retired Ceph OSD drive, deliberately: its
+# contents are reconstructible, so a worn disk is consumable here in a way it
+# is not as an OSD. Note /var/lib/etcd lives here too, which is the one thing
+# on the volume that is not free to lose.
 #
 # THIS ONLY TAKES EFFECT ON FIRST PROVISION. Talos applies volume configuration
 # solely when the volume does not yet exist; a config applied after EPHEMERAL
@@ -75,8 +40,8 @@ cluster:
 # requires wiping the disk and booting install media again.
 #
 # Matched by serial deliberately. `disk.transport == 'nvme' && !system_disk`
-# would match the PM983 as well, and losing that coin flip means Talos formats
-# the OSD drive.
+# still matches the OSD drive, and losing that coin flip means Talos formats
+# it.
 apiVersion: v1alpha1
 kind: VolumeConfig
 name: EPHEMERAL
@@ -86,30 +51,25 @@ provisioning:
  minSize: 50GiB
  grow: true
 ---
-# X710 port 0 carries the switch trunk. It takes no addressing itself — the
-# port's untagged VLAN is the 192.168.8.0/24 network, which this node has no
-# business being on — so management and v30iot both ride it as tagged VLANs.
+# X710 port 0 carries the switch trunk and takes no addressing itself — its
+# untagged VLAN is a network this node has no business being on. Management
+# and v30iot ride it as tagged VLANs.
 #
-# Links are addressed by predictable kernel name. Those derive from PCI
-# topology, not probe order — though not immune: adding the third NVMe
-# renumbered the buses and moved the unused second I226 from enp89s0 to
-# enp90s0. Neither name used here was affected.
+# Links are named by predictable kernel name, which derives from PCI topology
+# and can still shift when hardware is added.
 #
-# LinkAliasConfig would be the better way to pin these, and is worth
-# reintroducing — but only once it is proven. Aliasing both X710 ports by
-# permanent MAC and using the aliases as VLAN parents produced a node with no
-# address on any interface: the aliases were never created, so every document
-# referencing them did nothing, including the static address on port 1. Verify
-# any alias-based revision with `talosctl apply-config --mode=try`, which rolls
-# back on its own, before making it permanent.
+# LinkAliasConfig would pin these better, but aliasing the X710 ports by MAC
+# and using the aliases as VLAN parents left the node with no address on any
+# interface — the aliases were never created and every document referencing
+# them silently did nothing. Prove any alias-based revision with
+# `talosctl apply-config --mode=try` first; it rolls back on its own.
 apiVersion: v1alpha1
 kind: LinkConfig
 name: enp2s0f0np0
 up: true
 ---
 # Management, VLAN 40. Carries the node IP, etcd, the API and Ceph's public
-# network. The k8s-1 VM reached 10.2.40.174 over this same physical port via
-# Proxmox's v40srv VNet (vmbr0.40), so the switch trunks VLAN 40 here.
+# network.
 apiVersion: v1alpha1
 kind: VLANConfig
 name: mgmt0
@@ -117,30 +77,15 @@ vlanID: 40
 parent: enp2s0f0np0
 up: true
 ---
-# Management addressing is DHCP and the lease is NOT reserved anywhere in this
-# repo — the k8s-{1,2,3}.srv.renner.uno reservations live on the UDM out of band
-# and opentofu/unifi.tf declares no live resources. The addresses do move under
-# a running node: k8s-3 went 10.2.40.168 -> .138 mid-flight on 2026-08-26
-# without its Node object ever re-registering (issue #635).
+# DHCP, and the lease is not reserved in this repo — reservations live on the
+# UDM out of band. Addresses do move under a running node.
 #
-# kube-apiserver does not follow when that happens. Talos starts it with
-# `--advertise-address=$(POD_IP)` and no `--endpoint-reconciler-type` override,
-# so the advertised address is fixed at pod start and the default lease
-# reconciler goes on renewing the masterlease under the OLD address. Nothing
-# expires it while the process lives, so `default/kubernetes` keeps handing out
-# a dead endpoint and the node's live address is never registered at all — 19h
-# of TargetDown on job="apiserver", a monitoring blind spot on one of three
-# apiservers, and it cleared only when the static pod restarted.
-#
-# So after any node re-IPs, check that
+# kube-apiserver does not follow a re-IP: it advertises $(POD_IP) fixed at pod
+# start and the lease reconciler keeps renewing the masterlease under the old
+# address, so `default/kubernetes` hands out a dead endpoint until the static
+# pod restarts (#635). After any node re-IPs, check that
 # `kubectl get endpoints kubernetes -n default` agrees with
-# `kubectl get nodes -o wide`, and restart the offending node
-# (`talosctl -n <node> reboot`) if it does not.
-#
-# Pinning mgmt0 with a static AddressConfig alongside this document would remove
-# the trigger, but it needs an address outside the UDM's DHCP pool — which is
-# not declared in this repo — and §6 of RUNBOOK-baremetal-conversion.md applies:
-# prove it with `talosctl apply-config --mode=try` before making it permanent.
+# `kubectl get nodes -o wide` and reboot the node if it does not.
 apiVersion: v1alpha1
 kind: DHCPv4Config
 name: mgmt0
@@ -152,10 +97,8 @@ kind: Layer2VIPConfig
 name: 10.2.40.60
 link: mgmt0
 ---
-# Named ens19 on purpose. The four v30iot macvlan NADs hard-code
-# `master: ens19`, and k8s-2/k8s-3 still present the VLAN as a virtio NIC of
-# that name. VLANConfig.name is free-form, so keeping it lets one set of NADs
-# serve both VM and bare-metal nodes for as long as the cluster is mixed.
+# Named ens19 on purpose: the v30iot macvlan NADs hard-code `master: ens19`.
+# VLANConfig.name is free-form, so renaming this link means editing them too.
 apiVersion: v1alpha1
 kind: VLANConfig
 name: ens19
@@ -163,19 +106,13 @@ vlanID: 30
 parent: enp2s0f0np0
 up: true
 ---
-# Dedicated Ceph cluster network on X710 port 1, VLAN 49 / 10.99.0.0/29,
-# untagged on the wire. Carries OSD<->OSD replication and nothing else.
+# Dedicated Ceph cluster network on X710 port 1, VLAN 49, untagged on the
+# wire. OSD-to-OSD replication and nothing else.
 #
-# The node deliberately holds NO address here. Rook attaches this link to the
-# OSD pods through a Multus macvlan (infrastructure/rook-ceph-cluster/
-# san-network-attachment.yaml), and a macvlan parent only has to be up — it
-# does not need an address of its own for its children to work.
-#
-# It used to carry 10.99.0.1/29, because reaching this link required
-# CephCluster.spec.network.provider: host, and that put every Ceph daemon on
-# host networking, mons included. Nothing needs it now, and by the rule this
-# segment is built on — Ceph-internal traffic and nothing else — the node has
-# no business on it either.
+# The node holds NO address here on purpose. Rook attaches the link to the OSD
+# pods through a Multus macvlan, and a macvlan parent only needs to be up.
+# Giving the node an address would put it on a segment reserved for
+# Ceph-internal traffic.
 apiVersion: v1alpha1
 kind: LinkConfig
 name: enp2s0f1np1
@@ -9,20 +9,14 @@ machine:
    # macvlan parent for the v30iot pod attachments; host addresses on that L2
    # make node replies bypass the UDM and break every UDM-DNATed flow.
    net.ipv6.conf.ens19.disable_ipv6: "1"
-    # Same argument for the physical ports: enp2s0f0np0 is only the trunk
-    # parent for mgmt0 and ens19, enp87s0 is unused, and both sit on the
-    # untagged fallback network where nothing is supposed to run. Both were
-    # taking an fd00::/64 and an IPv6 default route from its router
-    # advertisements, leaving four equal-priority default routes per node of
-    # which only mgmt0 has a globally routable source. See k8s-1.yaml for the
-    # full reasoning and how it was verified.
+    # Same for the physical ports on the untagged fallback network: left
+    # enabled they take an IPv6 default route from its RAs and cost the
+    # cluster IPv6 egress.
    net.ipv6.conf.enp2s0f0np0.disable_ipv6: "1"
    net.ipv6.conf.enp87s0.disable_ipv6: "1"
  install:
-    # Three NVMe drives are visible on bare metal. Select the installer target
-    # by serial so it cannot land on the OSD drive or on EPHEMERAL, whatever
-    # order the kernel enumerates them in — Talos and Proxmox do not agree on
-    # that order.
+    # Select the installer target by serial so it cannot land on the OSD drive
+    # or on EPHEMERAL, whatever order the kernel enumerates them in.
    diskSelector:
      serial: 50026B7382DA5F6E
  certSANs:
@@ -32,17 +26,15 @@ machine:
 cluster:
  allowSchedulingOnControlPlanes: true
 ---
-# EPHEMERAL (/var) goes on the retired Crucial P3, not the system disk. That
-# drive is at 81% of its rated endurance and is finished as an OSD, but
-# everything EPHEMERAL holds is reconstructible, so it is consumable in this
-# role. It also gives /var ~931 GB instead of the 64 GB the VM-era zvol had.
+# EPHEMERAL (/var) goes on the retired Ceph OSD drive, deliberately: its
+# contents are reconstructible, so a worn disk is consumable in this role.
 #
 # ONLY TAKES EFFECT ON FIRST PROVISION. Talos applies volume configuration
 # solely when the volume does not yet exist; applied later it is silently
 # ignored and relocating needs a disk wipe and a boot from install media.
 #
 # Matched by serial deliberately: a broad selector such as
-# `disk.transport == 'nvme' && !system_disk` would match the PM983 as well.
+# `disk.transport == 'nvme' && !system_disk` still matches the OSD drive.
 apiVersion: v1alpha1
 kind: VolumeConfig
 name: EPHEMERAL
@@ -85,9 +77,8 @@ kind: Layer2VIPConfig
 name: 10.2.40.60
 link: mgmt0
 ---
-# Named ens19 on purpose: the four v30iot macvlan NADs hard-code
-# `master: ens19`, and k8s-3 still presents the VLAN as a virtio NIC of that
-# name. VLANConfig.name is free-form, so one set of NADs serves both.
+# Named ens19 on purpose: the v30iot macvlan NADs hard-code `master: ens19`.
+# VLANConfig.name is free-form, so renaming this link means editing them too.
 apiVersion: v1alpha1
 kind: VLANConfig
 name: ens19
@@ -95,18 +86,11 @@ vlanID: 30
 parent: enp2s0f0np0
 up: true
 ---
-# Dedicated Ceph cluster network on X710 port 1, VLAN 49 / 10.99.0.0/29,
-# untagged on the wire. OSD<->OSD replication only. Not routed off its own
-# segment and deliberately has no default route.
+# Dedicated Ceph cluster network on X710 port 1, VLAN 49, untagged on the
+# wire. OSD-to-OSD replication only, not routed off its own segment.
 #
-# The node deliberately holds NO address here. Rook attaches this link to the
-# OSD pods through a Multus macvlan (infrastructure/rook-ceph-cluster/
-# san-network-attachment.yaml), and a macvlan parent only has to be up — it
-# does not need an address of its own for its children to work.
-#
-# It used to carry 10.99.0.2/29, because reaching this link required
-# CephCluster.spec.network.provider: host, which put every Ceph daemon on
-# host networking, mons included. Nothing needs it now.
+# The node holds NO address here on purpose. Rook attaches the link to the OSD
+# pods through a Multus macvlan, and a macvlan parent only needs to be up.
 apiVersion: v1alpha1
 kind: LinkConfig
 name: enp2s0f1np1
@@ -1,27 +1,18 @@
-# k8s-3 runs Talos directly on neptune's MS-01 hardware. Structurally identical
-# to k8s-1.yaml — see that file for the reasoning behind each choice; only the
-# serials and addresses differ. neptune was the last node converted, so all
-# three control-plane nodes now share this layout and no Proxmox remains.
+# Structurally identical to k8s-1.yaml — see that file for the reasoning
+# behind each choice; only the serials and addresses differ.
 machine:
  network:
    hostname: k8s-3
  sysctls:
    # v30iot NIC carries no host addressing — see k8s-1.yaml.
    net.ipv6.conf.ens19.disable_ipv6: "1"
-    # Same argument for the physical ports: enp2s0f0np0 is only the trunk
-    # parent for mgmt0 and ens19, enp87s0 is unused, and both sit on the
-    # untagged fallback network where nothing is supposed to run. Both were
-    # taking an fd00::/64 and an IPv6 default route from its router
-    # advertisements, leaving four equal-priority default routes per node of
-    # which only mgmt0 has a globally routable source. See k8s-1.yaml for the
-    # full reasoning and how it was verified.
+    # Same for the physical ports on the untagged fallback network — see
+    # k8s-1.yaml.
    net.ipv6.conf.enp2s0f0np0.disable_ipv6: "1"
    net.ipv6.conf.enp87s0.disable_ipv6: "1"
  install:
-    # Three NVMe drives are visible on bare metal. Select the installer target
-    # by serial so it cannot land on the OSD drive or on EPHEMERAL, whatever
-    # order the kernel enumerates them in — Talos and Proxmox do not agree on
-    # that order.
+    # Select the installer target by serial so it cannot land on the OSD drive
+    # or on EPHEMERAL, whatever order the kernel enumerates them in.
    diskSelector:
      serial: 50026B7382B48B90
  certSANs:
@@ -31,10 +22,8 @@ machine:
 cluster:
  allowSchedulingOnControlPlanes: true
 ---
-# EPHEMERAL (/var) goes on the retired Crucial P3, not the system disk. That
-# drive is at 83% of its rated endurance and is finished as an OSD, but
-# everything EPHEMERAL holds is reconstructible, so it is consumable in this
-# role. Available spare is still 100% and it reports no media errors.
+# EPHEMERAL (/var) goes on the retired Ceph OSD drive, deliberately: its
+# contents are reconstructible, so a worn disk is consumable in this role.
 #
 # ONLY TAKES EFFECT ON FIRST PROVISION. Talos applies volume configuration
 # solely when the volume does not yet exist; applied later it is silently
@@ -81,15 +70,8 @@ vlanID: 30
 parent: enp2s0f0np0
 up: true
 ---
-# Dedicated Ceph cluster network — see k8s-1.yaml.
-# The node deliberately holds NO address here. Rook attaches this link to the
-# OSD pods through a Multus macvlan (infrastructure/rook-ceph-cluster/
-# san-network-attachment.yaml), and a macvlan parent only has to be up — it
-# does not need an address of its own for its children to work.
-#
-# It used to carry 10.99.0.3/29, because reaching this link required
-# CephCluster.spec.network.provider: host, which put every Ceph daemon on
-# host networking, mons included. Nothing needs it now.
+# Dedicated Ceph cluster network — see k8s-1.yaml. The node holds NO address
+# here on purpose; the link is only a macvlan parent for the OSD pods.
 apiVersion: v1alpha1
 kind: LinkConfig
 name: enp2s0f1np1
Author	SHA1	Message	Date
claude-bot	8ae1cc7187	docs(infra): cut the narration out of cephcluster and the velero schedules ci/woodpecker/pr/ci-scripts-test Pipeline was successful Details ci/woodpecker/pr/ci-manifests-test Pipeline was successful Details ci/woodpecker/pr/pr-review Pipeline was successful Details Comments only — filtering the diff for non-comment lines returns empty, and both files still parse and build. cephcluster.yaml goes from 224 comment lines to 76. Kept: that `ceph config` retains values which merely disappear from this file, so deleting a line does not restore a default and a live provider change needs `ceph config rm` first; that osdMaxUpdatesInParallel and upgradeOSDRequiresHealthyPGs are the only things keeping a rolling OSD change off all three replicas at once; that `addressRanges` drags the mons onto host networking and ties them to a DHCP lease; that devices are named by-id because kernel names move between boots; that the bluestore deferral settings must not be raised again. Cut from it: the paxos write-amplification measurement down to the byte, the history of why mon_data_avail_warn was once 20, and a table of every drive serial in the fleet sitting three lines above the by-id paths that already name them. velero-schedules.yaml loses a per-PVC inventory of the home-assistant namespace — eleven names, which had already been wrong once by two — in favour of saying the schedule sweeps the namespace. Two stale claims went with it. Both files said PVC contents are uploaded to Garage; the BackupStorageLocation reads bucket renner-uno-k8s-velero at fsn1.your-objectstorage.com, and Garage was retired to nas-1. And the ha-pg exclusion still explained itself by quoting the comment it had replaced.	2026-08-28 06:39:44 +02:00
k.renner	633a141bac	Merge pull request 'docs(talos): cut the narration out of the machine config patches' (#680 ) from trim-comments-talos into master Reviewed-on: k.renner/homelab#680	2026-08-28 04:34:43 +00:00
claude-bot	ed86592978	docs(talos): cut the narration out of the machine config patches ci/woodpecker/pr/ci-manifests-test Pipeline was successful Details ci/woodpecker/pr/ci-scripts-test Pipeline was successful Details ci/woodpecker/pr/pr-review Pipeline was successful Details 242 comment lines out, 91 in, across the four hand-written Talos patches. The diff touches nothing but comments — filtering it for non-comment lines returns empty. Kept, because each changes what someone editing that line would do: select disks by serial or the installer takes the OSD drive; EPHEMERAL volume config applies only on first provision and is silently ignored afterwards; the LinkAliasConfig attempt that left a node with no address on any interface; kube-apiserver not following a node re-IP; the fallback-network links must stay v6-disabled or the cluster loses IPv6 egress; the installer image is Image Factory and not the stock one, and its tag must match the version being upgraded to. Cut: how each of those was discovered. The four-equal-priority-routes investigation, the 30 hours of NetBird probes, the image-GC measurement on k8s-2 down to the percentage point, the per-extension rationale for the schematic. All of it is in the commit history and the wiki. Cut as stale rather than merely long, which is the point of doing this at all: - k8s-1.yaml opened by saying k8s-2 and k8s-3 are still Proxmox VMs. All three have been bare metal since neptune's conversion; DMI reports Minisforum on every one. - two files justified a disk selector with "Talos and Proxmox do not agree on that order". There is no Proxmox. - three files carried per-drive wear figures (87%, 81%, 83%) and one an exact media-error count. Those are measurements, they move, and a config file never gets re-read when they do. - the mgmt0 note explained VLAN 40 by way of which address the k8s-1 VM used to reach over that port. One thing removed here has no other home: whether k8s-1's 18 media errors are historical or ongoing was written up in this file and nowhere else, and #549 is closed. Tracking it separately rather than losing it.	2026-08-28 06:27:57 +02:00
k.renner	a8c2f79f84	Merge pull request 'fix: [alert] NvmeDriveWearHigh (monitoring) (#675 )' (#679 ) from alert-fix/issue-675 into master ci/woodpecker/cron/alert-monitor Pipeline was successful Details Reviewed-on: k.renner/homelab#679	2026-08-28 04:21:02 +00:00
k.renner	9f10ea793d	Merge pull request 'docs: cut the essays out of the manifests I wrote today' (#678 ) from trim-manifest-comments into master Reviewed-on: k.renner/homelab#678	2026-08-28 04:20:33 +00:00
issue-fix-bot	bdffe1804b	fix: [alert] NvmeDriveWearHigh (monitoring) (#675 ) ci/woodpecker/pr/ci-scripts-test Pipeline was successful Details ci/woodpecker/pr/ci-manifests-test Pipeline was successful Details ci/woodpecker/pr/pr-review Pipeline was successful Details	2026-08-27 19:45:14 +00:00
claude-bot	da1482e33f	docs: cut the essays out of the manifests I wrote today ci/woodpecker/pr/ci-scripts-test Pipeline was successful Details ci/woodpecker/pr/ci-manifests-test Pipeline was successful Details ci/woodpecker/pr/pr-review Pipeline was successful Details Config files were carrying investigation write-ups: two ruled-out hypotheses in the smartctl-exporter securityContext, a twenty-line canonical note on the Hetzner credential, the history of an alert threshold. That is derivation, not configuration, and it belongs where it does not rot — the commit message for how we got here, the wiki for what holds. The distinction this applies: a comment stays if it changes what someone editing that line would do — a constraint of the tool, a trap, a pointer to an issue. It goes if it narrates how a conclusion was reached, restates a measurement, or justifies a value after the fact. The test is whether the surrounding config could change and leave the comment quietly wrong. 160 lines out, 30 in. Nothing behavioural changed; both manifests still pass a server-side dry run. Alert descriptions were tightened rather than removed. Those are not comments — they are what someone reads when paged, and an essay is worse there than anywhere. This covers only what I added today. The repo has roughly 8600 comment lines with 88 files over 25, and going further needs the criterion above agreed first — much of that volume is load-bearing warning rather than narration.	2026-08-27 21:37:20 +02:00
k.renner	c6b1aa109b	Merge pull request 'refactor(secrets): drop the unused barman-cloud-creds' (#677 ) from drop-unused-barman-creds into master ci/woodpecker/cron/issue-fix Pipeline was successful Details ci/woodpecker/cron/alert-monitor Pipeline was successful Details Reviewed-on: k.renner/homelab#677	2026-08-27 19:20:01 +00:00
claude-bot	2f3d952656	refactor(secrets): drop the unused barman-cloud-creds ci/woodpecker/pr/ci-scripts-test Pipeline was successful Details ci/woodpecker/pr/ci-manifests-test Pipeline was successful Details ci/woodpecker/pr/pr-review Pipeline was successful Details Three ExternalSecrets synced a Secret that nothing reads. Established rather than assumed, from three directions: every live ObjectStore names hetzner-s3-creds, no CNPG Cluster uses the legacy inline barmanObjectStore (all seven run the barman-cloud plugin against an ObjectStore CR), and no pod in the cluster mounts barman-cloud-creds. They are almost certainly left from before the plugin migration, when the inline configuration read a Secret of that name. Worth stating plainly because it is not merely untidy: seed/{authentik,immich, paperless}/barman-creds hold a Hetzner S3 credential that is NOT the one in use. Fingerprint c2c5cf3e against 87954b64 for the live hetzner-s3 path, with the three copies identical to each other. A valid key with no consumer is exposure without benefit, so if it is a distinct S3 key it wants revoking at Hetzner, which only a human can do — deleting our copies does not. Removing the manifests does NOT remove the objects. All three carry kustomize.toolkit.fluxcd.io/prune: disabled from the seed->app-KS handoffs, so Flux skips them during garbage collection by design. The ExternalSecrets, their Secrets and the three OpenBao paths have to be deleted explicitly after this merges; git alone leaves them live and orphaned, which is worse than leaving them declared. The OpenBao paths deliberately stay until then. Deleting them first would leave three ExternalSecrets failing to sync against a key that no longer exists, for no gain.	2026-08-27 21:18:08 +02:00
k.renner	0a87f91116	Merge pull request 'refactor(secrets): one OpenBao path for the one Hetzner S3 credential' (#676 ) from hetzner-creds-shared-path into master ci/woodpecker/cron/alert-monitor Pipeline was successful Details Reviewed-on: k.renner/homelab#676	2026-08-27 19:04:23 +00:00
claude-bot	c59f0050b3	refactor(secrets): one OpenBao path for the one Hetzner S3 credential ci/woodpecker/pr/ci-scripts-test Pipeline was successful Details ci/woodpecker/pr/ci-manifests-test Pipeline was successful Details ci/woodpecker/pr/pr-review Pipeline was successful Details #397 asked for the opposite: give woodpecker its own path so a rotation of paperless's credentials would stop silently changing woodpecker's. The premise does not hold. There is one Hetzner S3 key, and rotating it at Hetzner changes it for every consumer no matter how many paths hold a copy. A fifth copy would have bought nothing and made the separation look real. Seven ExternalSecrets were reading it from four paths — seed/paperless (four namespaces), seed/authentik, seed/immich, seed/trmnl. They now all read infrastructure/hetzner-s3, which sits beside the existing infrastructure/velero-hetzner. That the four paths are byte-identical was verified rather than assumed, and without reading them: SHA-256 over the three fields of each synced Secret returns the same fingerprint in all seven namespaces. The same check says infrastructure/velero-hetzner carries the same access key id, in a different shape — a single `cloud` field holding an AWS credentials file. Velero is deliberately not folded in. Moving it means templating that INI from these fields, which is worth doing and not worth bundling with a path swap that touches every database backup at once. The reasoning lives once, in the paperless manifest, with the others pointing at it. Repeating it six times is how six copies drift. Kept from the note this replaces, because it was right and cost someone an afternoon: the 403 recorded in #397 was a wrong-path error, not missing permissions. The mount is `homelab`, so the path is homelab/seed/... — `bao kv list homelab/seed` works with the identity available here. homelab/infrastructure/hetzner-s3 now exists, copied from the paperless path inside OpenBao so the value never left it, and fingerprints identical to its source. Writes turned out to be possible all along: they fail through openbao.renner.uno with a response the client cannot parse, and succeed against the Service. That is worth knowing before the next person concludes, as I first did, that the identity is read-only. Closes #397	2026-08-27 21:02:28 +02:00
k.renner	48c46610a6	Merge pull request 'docs(monitoring): stop treating a worn EPHEMERAL drive as a hazard' (#674 ) from ephemeral-framing into master ci/woodpecker/cron/issue-fix Pipeline was successful Details ci/woodpecker/cron/alert-monitor Pipeline was successful Details Reviewed-on: k.renner/homelab#674	2026-08-27 18:38:33 +00:00
claude-botandClaude Opus 5	53887dd88f	docs(monitoring): stop treating a worn EPHEMERAL drive as a hazard ci/woodpecker/pr/ci-scripts-test Pipeline was successful Details ci/woodpecker/pr/ci-manifests-test Pipeline was successful Details ci/woodpecker/pr/pr-review Pipeline was successful Details I described the worn drives carrying EPHEMERAL as the dangerous placement, repeatedly, in the alert text and in the dashboard's caveats. That reads the volume backwards. EPHEMERAL is Talos's /var and its contents are meant to be disposable — container images, kubelet state, pod scratch, spegel and Rook's local state all rebuild. Putting the drives with the least endurance left there is a sensible destination, not a risk someone should be warned about. The alert said "a node simply stops when it goes", which is simply wrong. A node losing /var rebuilds it. What survives the correction is narrower and checked rather than recalled: /var/lib/etcd is on that volume too, so losing EPHEMERAL on a control-plane node costs that member's data. Quorum holds at two of three and the member is removed and re-added. That is a rebuild, not data loss, and the alert now says so at that weight. The fill-level panel keeps its warning but for the right reason: a full /var stops a node being useful long before anything is lost, and nothing rebalances it the way Ceph rebalances a full OSD. That is a capacity argument, not an endurance one. None of this changes the monitoring — measuring every drive is still right, and the wear figures are unchanged. It changes what a reader is told the numbers mean, which is the part that was misleading. Refs #549 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-27 20:35:11 +02:00
k.renner	c9a10ab015	Merge pull request 'feat(monitoring): put the SMART values on the dashboard' (#672 ) from disk-dashboard-smart into master ci/woodpecker/cron/issue-fix Pipeline was successful Details ci/woodpecker/cron/alert-monitor Pipeline was successful Details Reviewed-on: k.renner/homelab#672	2026-08-27 13:27:36 +00:00
claude-botandClaude Opus 5	24b2a0178d	feat(monitoring): put the SMART values on the dashboard ci/woodpecker/pr/ci-scripts-test Pipeline was successful Details ci/woodpecker/pr/ci-manifests-test Pipeline was successful Details ci/woodpecker/pr/pr-review Pipeline was successful Details The exporter reports all nine drives now, so the dashboard shows what it measures: a worst-wear stat in the status row, wear per drive over time, and a table of the failure-now signals — available spare, media errors, the critical warning bitfield, power-on time and written bytes. Every expression was run against the live TSDB and the label names read off real series rather than a README. That mattered: the exporter labels devices `nvme0` and carries model and serial on a separate `smartctl_device` info metric, so each query joins on (node, device) to pull the model in. A legend on the device name alone would compare different hardware across machines, which is the same trap the block-layer panels already avoid. Wear and damage are presented as different things because they are. The wear percentage is a budget the drive spends and says nothing about tomorrow; spare exhaustion, media errors and the critical warning mean something is wrong now. The caveats panel says so, and no longer claims endurance is missing — it was missing when that text was written and is not any more. Also fixes the OSD stat, which still rendered two identical numbers side by side. The commit that fixed it did not make it into #668 before that PR merged, so the panel went out in the state that prompted the complaint. It now shows OSDs down alone; up-but-out is a state rather than a fault and Ceph warns about it separately. Refs #549 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-27 15:26:09 +02:00
k.renner	b8061ea05d	Merge pull request 'fix(monitoring): privileged is the mechanism, not the shortcut' (#671 ) from smartctl-privileged into master Reviewed-on: k.renner/homelab#671	2026-08-27 13:19:38 +00:00
claude-botandClaude Opus 5	d0bea0dc15	fix(monitoring): privileged is the mechanism, not the shortcut ci/woodpecker/pr/ci-scripts-test Pipeline was successful Details ci/woodpecker/pr/ci-manifests-test Pipeline was successful Details ci/woodpecker/pr/pr-review Pipeline was successful Details Third attempt, and the first two were wrong for the same reason: I kept looking for the gate in the capability and syscall layers, and it was never there. Attempt one gave the container CAP_SYS_ADMIN and CAP_SYS_RAWIO with everything else dropped. It found all three drives per node and could open none of them. Attempt two added seccompProfile: Unconfined, reasoning that EPERM is the default action for a syscall an unlisted profile blocks and that the kubelet runs seccompDefault: true. /proc/1/status confirmed both capabilities effective and a filter loaded, so the theory was at least testable — and removing the filter changed nothing. What settled it was a smaller test than either: `head -c 512 /dev/nvme0n1` inside the container also fails with EPERM. Reading a block device involves no ioctl, no capability and nothing a seccomp profile filters. The denial is the device cgroup, which containerd applies to every non-privileged container regardless of whether /dev is mounted. Mounting /dev makes the nodes visible; it does not make them usable. Kubernetes has no per-device allowlist in a Pod spec — no equivalent of `docker --device`. So the honest position is that `privileged: true` here is not a lazy shortcut standing in for a narrower setting; it is the only mechanism the API offers, short of writing a device plugin. The manifest now says that, and records what was ruled out and how, so the next reader does not spend the same two rounds in the capability layer. The /dev mount loses its readOnly flag with it. smartmontools opens NVMe devices read-write on some paths, and once the container is privileged that flag suggests a boundary that is not there. A device plugin advertising the drives as a schedulable resource is the genuinely narrower answer and is noted as such. It is worth building when more than one workload needs raw device access; for a single read-only metrics exporter it is a component to write, deploy and maintain in exchange for the same access. Refs #549 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-08-27 15:14:32 +02:00
k.renner	8ccf5ac8e5	Merge pull request 'fix(monitoring): unconfine seccomp so smartctl can open the devices' (#670 ) from smartctl-seccomp into master ci/woodpecker/cron/alert-monitor Pipeline was successful Details Reviewed-on: k.renner/homelab#670	2026-08-27 13:05:08 +00:00