mirror of
https://github.com/cozystack/cozystack.git
synced 2026-11-03 10:37:21 +09:00
Migration slot 45 holds a different migration here than on main and release-1.6. On this branch it is the seaweedfs db-split repair, added after v1.5.3 by `33611dfe7` (the #3370 backport), which in the same commit bumped `migrations.targetVersion` from 45 to 46. On main and 1.6 slot 45 is the `helm.sh/resource-policy=keep` pin on `KubeadmConfigTemplate`, and the seaweedfs repair sits at slot 53 instead. Nothing is broken today. v1.5.0 through v1.5.3 all ship `targetVersion: 45`, so no released cluster is stamped past it and every one of them still runs 1.6's slot 45 on the way up. Cutting v1.5.4 is what first ships 46. After that a 1.5.4 to 1.6 upgrade runs `seq 46 53` and never executes 1.6's slot 45, so helm prunes `KubeadmConfigTemplate` while the live kubeadm-backed MachineSet still references it, `bootstrap.configRef` dangles and controller-manager floods through the talos worker rollover. Tenant kubernetes only, noisy broken upgrade rather than data loss. This folds the keep-pin into release-1.5's slot 45 so it does both jobs, and puts the annotation on the rendered template in `packages/apps/kubernetes/templates/cluster.yaml` so templates created after the upgrade are born pinned. `targetVersion` stays 46. ### Why uninstall does not leak `keep` suppresses only helm's own delete. CAPI stamps an `ownerReference` to the `Cluster` on this object, which the chart does not render (checked on a live v1.5 stand, and `MachineDeployment` and `KubevirtMachineTemplate` carry the same reference). The `Cluster` itself is helm-managed with no `keep`, so `helm uninstall` deletes it and GC reclaims the template through that reference. Template name is deterministic rather than content-hashed, so `keep` cannot accumulate a copy per upgrade. One residue is the template of a removed nodeGroup, which helm no longer prunes. It is inert, re-adopted in place if the group comes back, and GC takes it with the `Cluster`. ### Tests Mutation-proven rather than revert-tested. The one worth naming: swapping the selector to the `meta.helm.sh/release-name` annotation makes the migration exit 0 reporting `pinned=0 failures=0`, which looks like a clean run, and the test catches it because the annotation never reached the object. Also converts four pre-existing negated-grep assertions in `hack/seaweedfs-guard-parity.bats`. `! grep -q X f` cannot fail, posix and bash both exempt a `!`-negated pipeline from errexit, so those were comments that look like assertions. All of them hold once they are real.