From f11cecc6970c51d9eb0d2a6c5810b3c5a9659d88 Mon Sep 17 00:00:00 2001 From: Ege Zambelli Date: Mon, 12 Oct 2026 09:43:53 +0200 Subject: [PATCH] helm: keep the S3 config checksum stable across the first upgrade (fixes #11719) (#11720) * helm: keep the S3 config checksum stable across the first upgrade (fixes #11719) checksum/s3config hashed the rendered s3-secret.yaml. That template keeps its generated S3 keys with lookup, so rendering it again for the checksum drew new keys whenever lookup found nothing: on install the filer, S3 and all-in-one pods each carried a checksum of a different set of keys than the Secret got, and the first upgrade with unchanged values corrected it and restarted them. Hash the values s3-secret.yaml is built from instead: the enable and auth switches, existingConfigSecret, credentials, the legacy-secret settings, the audit log configs and the Secret name. Only those, so scaling the S3 gateway or changing its resources does not restart the filer. A change to any of them still restarts the pods. Keys that the chart generated stay out of the hash; they only change if the Secret is deleted by hand. The new render test fails on the old template (two checksums for one Secret, different on every render) and passes now; it also checks that the checksum follows the credentials and filer.s3.auditLogConfig and ignores s3.replicas and s3.resources. On kind, an upgrade with unchanged values no longer replaces the filer pod. * helm: check the S3 checksum per workload, all-in-one included Each workload's checksum/s3config is now read on its own (--show-only), so a workload that loses the annotation fails the test instead of being hidden by sort -u, and the all-in-one deployment gets the same checks. Verified against two broken copies: one without the filer annotation, one with the old all-in-one checksum; the test fails on both. The helper comment now says what happens when the Secret is deleted to rotate generated keys. * ci(helm): fail the S3 checksum test on a missing or unrendered checksum A failed helm template or a render without the annotation produced an empty checksum, and the inequality assertions then passed against it. s3_checksum now returns non-zero unless it found a checksum, and the changed-value renders are assigned before comparing so failures cannot hide inside test. Generated with [Devin](https://devin.ai) Co-Authored-By: Devin <158243242+devin-ai-integration[bot]@users.noreply.github.com> --------- Co-authored-by: Ege Zambelli Co-authored-by: Chris Lu Co-authored-by: Devin <158243242+devin-ai-integration[bot]@users.noreply.github.com> --- .github/workflows/helm_ci.yml | 35 +++++++++++++++++++ .../all-in-one/all-in-one-deployment.yaml | 2 +- .../templates/filer/filer-statefulset.yaml | 2 +- .../seaweedfs/templates/s3/s3-deployment.yaml | 2 +- .../seaweedfs/templates/shared/_helpers.tpl | 25 +++++++++++++ 5 files changed, 63 insertions(+), 3 deletions(-) diff --git a/.github/workflows/helm_ci.yml b/.github/workflows/helm_ci.yml index 0ff81e9db..a8edb53a8 100644 --- a/.github/workflows/helm_ci.yml +++ b/.github/workflows/helm_ci.yml @@ -95,6 +95,41 @@ jobs: grep -A 5 "^ lifecycle:" /tmp/s3-rollout.yaml | grep -q -- "- sleep" echo "S3 rollout settings render correctly" + echo "=== Testing the S3 config checksum is stable across renders ===" + # s3-secret.yaml keeps its generated keys with lookup. Hashing the rendered + # Secret drew new keys for the checksum whenever lookup found nothing (on + # install), so the first upgrade changed the checksum and restarted the + # filer and S3 pods although nothing had changed. + s3_checksum() { #