admin/cozystack
1
0 Fork 0
mirror of https://github.com/cozystack/cozystack.git synced 2026-11-09 14:02:56 +09:00
Code Issues Packages Projects Releases Wiki Activity

chore(kubernetes): make migration 45 executable and drop tracking-PR refs

Browse Source 
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 <myasnikovdaniil2001@gmail.com>
This commit is contained in:
Myasnikov Daniil committed 2026-06-24 22:19:46 +05:00
1 parent a4c6a07b51
commit bf92f3f3b2
2 files changed
+11 -8
Download Patch File Download Diff File Expand all files Collapse all files

No files matched your search

packages/core/platform/images/migrations/migrations/45
Regular → Executable
+10 -7
View File
@@ -1,10 +1,10 @@
#!/bin/bash
# Migration 45 --> 46
# Pin KubeadmConfigTemplate / KubeadmConfig objects with helm.sh/resource-policy=keep
# so the Talos migration (PR #2610) does not let Helm prune them while CAPI still
# so the Talos worker migration does not let Helm prune them while CAPI still
# references them from the existing kubeadm-backed MachineSet.
#
# PR #2610 drops KubeadmConfigTemplate from the kubernetes app chart templates
# This release drops KubeadmConfigTemplate from the kubernetes app chart templates
# entirely (workers move to TalosConfigTemplate). On upgrade Helm sees the
# resource present in the previous release manifest but absent in the new one
# and issues a delete. The old MachineSet, which is still around until CAPI
@@ -14,11 +14,14 @@
# MachineHealthCheck remediation, etc.) workers can hang in pending state with
# nothing to bootstrap from.
#
# The fix is to annotate every Helm-managed KubeadmConfigTemplate (and the
# KubeadmConfig instances spawned from them) with helm.sh/resource-policy=keep
# *before* the new chart renders. Helm then leaves the object alone, CAPI keeps
# its references intact, and the resources disappear naturally when the old
# MachineSet is finally garbage-collected after the Talos rollover completes.
# The fix is to annotate every Helm-managed KubeadmConfigTemplate (and any
# Helm-managed KubeadmConfig) with helm.sh/resource-policy=keep *before* the new
# chart renders. The KubeadmConfig children CAPI spawns from the template are
# owned by their Machine, not Helm (no app.kubernetes.io/managed-by=Helm label),
# so Helm never prunes them and the managed-by selector below leaves them alone.
# Helm then leaves the template alone, CAPI keeps its references intact, and the
# resources disappear naturally when the old MachineSet is finally
# garbage-collected after the Talos rollover completes.
#
# Idempotent: re-running on already-annotated objects is a no-op
# (kubectl annotate --overwrite tolerates the existing value).
packages/core/platform/images/migrations/migrations/46
+1 -1
View File
@@ -2,7 +2,7 @@
# Migration 46 --> 47
# Bump kuberneteses.apps.cozystack.io spec.version from "v1.30" to "v1.31".
#
# PR #2610 drops v1.30 from the Talos<->Kubernetes support matrix: Talos v1.13
# This release drops v1.30 from the Talos<->Kubernetes support matrix: Talos v1.13
# (the version this chart pins for worker images) supports only k8s 1.31-1.36.
# The chart now refuses to render with version: "v1.30" via an explicit fail()
# guard in templates/_versions.tpl. Without this migration, tenants that were