chore(talos): move to v1.13.9

Nodes run v1.12.11, which is the last 1.12 patch — v1.12.12 does not exist. v1.13.9 is current. The upgrade path is the documented one rather than a shortcut. Migration is only tested between adjacent minor releases, and the recommendation is to go to the latest patch of each intermediate minor. 1.12.11 -> 1.13.9 satisfies both: one minor step, taken from the last patch of the version being left. No intermediate hop is needed. Kubernetes is not forced along. Talos 1.13's support matrix lists 1.36, 1.35, 1.34, 1.33, 1.32 and 1.31, and the cluster runs 1.35.2 — so it stays there until `talosctl upgrade-k8s` moves it as a separate decision. This was the one open question before the jump and it is answered from the matrix rather than assumed. Deprecations in 1.13 were checked against this cluster, not just read: .machine.env -> EnvironmentConfig not used .machine.network.kubespan -> KubeSpanConfig not used EtcdConfigs/KubeletConfigs protobuf change no consumer in this repo legacy upgrade API -> LifecycleService still functional; `talosctl upgrade` keeps working, this only matters once it is removed Both the five machine-config files here and the live config on k8s-1 were checked for the first two, because the running config is generated from a base this repo only patches and could carry fields the patches never mention. Neither appears in either. The removed interactive installer and the dropped `talosctl install` do not apply — installation here is `talosctl upgrade --image` and Image Factory media. Schematic is unchanged; the factory image was verified to exist for the new tag before committing. The cold-rebuild ISO URL moves with it. Not applied to any node. Rolling it out is drain -> upgrade -> wait for Ceph to return to 217 PGs active+clean, one node at a time, as in the 1.12.11 run. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Merge pull request 'chore(rook-ceph): return mon_data_avail_warn to the Ceph default' (#655 ) from ceph-mon-disk-warn-default into master
2026-08-27 08:56:20 +02:00 · 2026-08-27 06:40:38 +00:00
2 changed files with 11 additions and 2 deletions
@@ -87,7 +87,7 @@ all three nodes identically from there, since `apply-config --insecure` does
 not care whether the target is a VM or bare metal.

 ```
-https://factory.talos.dev/image/0f6fb8bd8bb53013e9743b7c7b099d96fb9c32fd2464ced32693c2dc0ea5feb9/v1.12.11/metal-amd64.iso
+https://factory.talos.dev/image/0f6fb8bd8bb53013e9743b7c7b099d96fb9c32fd2464ced32693c2dc0ea5feb9/v1.13.9/metal-amd64.iso
 ```

 That schematic is deliberately not the one `.woodpecker/deploy-infrastructure.yml`
@@ -42,8 +42,17 @@ machine:
  # 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.
  install:
-    image: factory.talos.dev/metal-installer/0f6fb8bd8bb53013e9743b7c7b099d96fb9c32fd2464ced32693c2dc0ea5feb9:v1.12.11
+    image: factory.talos.dev/metal-installer/0f6fb8bd8bb53013e9743b7c7b099d96fb9c32fd2464ced32693c2dc0ea5feb9:v1.13.9
  features:
    rbac: true
    stableHostname: true