Argo CD 3.x adds pre-delete-finalizer.argocd.argoproj.io and its /cleanup variant to Applications with PreDelete hooks, which the Longhorn chart has. With only resources-finalizer in git, the apps app-of-apps stayed OutOfSync on helm-longhorn.
Over the first 40 minutes after the restart: snapshots 24.7 minutes apart instead of ~3, none of 9,445 lease updates took over 4s, and neither the CNPG operator nor the snapshot-controller restarted.
1.34 brings the reworked k8s-dqlite write path, 1.36 a dqlite that can VACUUM the mostly empty datastore. Lists the per-hop checks, the one-way schema migration at 1.34, the components that still need to move for 1.35/1.36, and the staged dqlite tuning script on opti1.
The dqlite SQLite file is ~709 MB with 95% free pages, so every 1,024 commits dqlite writes a ~150 MB snapshot that stalls commits for seconds and makes controllers lose leader election. Plan: larger snapshot threshold in tuning.yaml now, microk8s 1.34+ for the real fix.
Required from 3.3, whose ApplicationSet CRD no longer fits the last-applied annotation of client-side apply. Turned on while still on 3.2 so the managed-field migration happens before the CRD grows.
Argo CD 3.0 switches the default to annotation tracking. Per the 2.14->3.0
upgrade notes, a resource whose first sync after the switch is a deletion
gets orphaned instead of pruned. Pinning label tracking (the 2.14 default,
so no change today) keeps the upgrade to 3.x free of that; moving to
annotations can follow once everything runs 3.4.
ESO 0.16.2 is the one release that serves both v1beta1 and v1. 0.17
stops serving v1beta1, so manifests still on v1beta1 would fail to sync
from the next hop on. For these resources the schemas are name-identical
(conversion strategy None); only the apiVersion changes.
Needed from ESO 0.19, whose CRDs are too big for client-side apply. Turned on now, on 0.10.7, so Argo CD migrates the managed fields before the upgrade starts.
Dropping the anti-affinity wasn't enough: during the rollout the old ReplicaSet kept recreating its pod with the old anti-affinity, which still blocked the new one. Recreate stops the old pod first; nothing uses the injector, so the short gap doesn't matter.
The chart requires injector pods on different nodes. With one node and one replica the rolling update to vault-k8s 1.7.6 deadlocked: the new pod stayed Pending until the old one left, which waits for the new one. The server already sets affinity to "" for the same reason.
Chart 0.28.1 is only tested up to Kubernetes 1.30. 0.34.1 brings the
injector to vault-k8s 1.7.6. The server image is pinned to the running
1.17.2: the StatefulSet uses OnDelete, so nothing restarts now, but a
later pod restart would otherwise pull the chart's default and Shamir
unsealing needs the keys at hand for a Vault upgrade. Rendered with the
pin, the StatefulSet only changes in formatting and an extra check in the
config script that doesn't apply here.
Ruben Hensen