Skip to content

Commit bf92f3f

Browse files
myasnikovdaniilmyasnikovdaniil
committed
chore(kubernetes): make migration 45 executable and drop tracking-PR refs
Set the executable bit on migration 45 to match its siblings (44, 46). Replace "PR #2610" references in migrations 45/46 with a description of the change. Correct migration 45's comment: the KubeadmConfig children CAPI spawns from the template are owned by their Machine (not Helm), so they carry no app.kubernetes.io/managed-by=Helm label, are not matched by the selector, and are never at risk of Helm pruning. Signed-off-by: Myasnikov Daniil <[email protected]>
1 parent a4c6a07 commit bf92f3f

2 files changed

Lines changed: 11 additions & 8 deletions

File tree

  • packages/core/platform/images/migrations/migrations

‎packages/core/platform/images/migrations/migrations/45‎

100644100755
Lines changed: 10 additions & 7 deletions
Original file line numberDiff line numberDiff line change
@@ -1,10 +1,10 @@
11
#!/bin/bash
22
# Migration 45 --> 46
33
# Pin KubeadmConfigTemplate / KubeadmConfig objects with helm.sh/resource-policy=keep
4-
# so the Talos migration (PR #2610) does not let Helm prune them while CAPI still
4+
# so the Talos worker migration does not let Helm prune them while CAPI still
55
# references them from the existing kubeadm-backed MachineSet.
66
#
7-
# PR #2610 drops KubeadmConfigTemplate from the kubernetes app chart templates
7+
# This release drops KubeadmConfigTemplate from the kubernetes app chart templates
88
# entirely (workers move to TalosConfigTemplate). On upgrade Helm sees the
99
# resource present in the previous release manifest but absent in the new one
1010
# and issues a delete. The old MachineSet, which is still around until CAPI
@@ -14,11 +14,14 @@
1414
# MachineHealthCheck remediation, etc.) workers can hang in pending state with
1515
# nothing to bootstrap from.
1616
#
17-
# The fix is to annotate every Helm-managed KubeadmConfigTemplate (and the
18-
# KubeadmConfig instances spawned from them) with helm.sh/resource-policy=keep
19-
# *before* the new chart renders. Helm then leaves the object alone, CAPI keeps
20-
# its references intact, and the resources disappear naturally when the old
21-
# MachineSet is finally garbage-collected after the Talos rollover completes.
17+
# The fix is to annotate every Helm-managed KubeadmConfigTemplate (and any
18+
# Helm-managed KubeadmConfig) with helm.sh/resource-policy=keep *before* the new
19+
# chart renders. The KubeadmConfig children CAPI spawns from the template are
20+
# owned by their Machine, not Helm (no app.kubernetes.io/managed-by=Helm label),
21+
# so Helm never prunes them and the managed-by selector below leaves them alone.
22+
# Helm then leaves the template alone, CAPI keeps its references intact, and the
23+
# resources disappear naturally when the old MachineSet is finally
24+
# garbage-collected after the Talos rollover completes.
2225
#
2326
# Idempotent: re-running on already-annotated objects is a no-op
2427
# (kubectl annotate --overwrite tolerates the existing value).

‎packages/core/platform/images/migrations/migrations/46‎

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -2,7 +2,7 @@
22
# Migration 46 --> 47
33
# Bump kuberneteses.apps.cozystack.io spec.version from "v1.30" to "v1.31".
44
#
5-
# PR #2610 drops v1.30 from the Talos<->Kubernetes support matrix: Talos v1.13
5+
# This release drops v1.30 from the Talos<->Kubernetes support matrix: Talos v1.13
66
# (the version this chart pins for worker images) supports only k8s 1.31-1.36.
77
# The chart now refuses to render with version: "v1.30" via an explicit fail()
88
# guard in templates/_versions.tpl. Without this migration, tenants that were

0 commit comments

Comments
 (0)