feat(etcd-operator): bump to v0.5.3 (S3 checksum fix for non-AWS backends) - #3403
Conversation
…ends) v0.5.3 carries the S3 request-checksum fix (cozystack/etcd-operator#342): the snapshot agent sets RequestChecksumCalculation=WhenRequired on BOTH the S3 client and the transfer manager, so multipart snapshot uploads (>5 MiB — every real etcd snapshot) no longer carry the CRC32 STREAMING-UNSIGNED-PAYLOAD-TRAILER that Ceph RGW rejects with 400 InvalidArgument. Also pulls in #340 (observed EtcdMember versions) and #341 (--watch-namespace). - system/etcd-operator: appVersion v0.5.2 -> v0.5.3 (image tag follows AppVersion), bump ETCD_OPERATOR_REF, update deployment unittest expectations. - system/etcd-operator-crds: re-vendor CRDs from v0.5.3. etcdmembers gains the additive #340 status.version field + "Running" printer column and picks up the peerAutoTLS spec field the vendored copy was already missing (all additive, backward-compatible; etcdclusters/etcdsnapshots unchanged). Fix the stale `make update`: upstream has no config/crd kustomization — CRDs live in charts/etcd-operator/crd-bases — so vendor those directly and stamp helm.sh/resource-policy: keep. Verified end-to-end on a Ceph RGW backend: the v0.5.2 (client-only) agent fails a multipart snapshot upload with the 400 above; v0.5.3 uploads an 11 MiB multipart snapshot successfully. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> Signed-off-by: Andrey Kolkov <andrey.kolkov@aenix.io>
📝 WalkthroughWalkthroughThe etcd-operator references are updated from v0.5.2 to v0.5.3. CRDs are vendored from upstream chart sources, the Changesetcd-operator v0.5.3 update
Estimated code review effort: 2 (Simple) | ~10 minutes Suggested reviewers: 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
|
Caution The consumer version of Gemini Code Assist on GitHub has been sunset. All code review activity has officially ceased. |
There was a problem hiding this comment.
🧹 Nitpick comments (1)
packages/system/etcd-operator-crds/Makefile (1)
17-21: 📐 Maintainability & Code Quality | 🔵 Trivial | ⚡ Quick winFail the build if the CRD download fails.
In the shell
forloop, ifcurlfails (e.g., due to a 404 or network error), the pipeline might continue and write an empty or incomplete file. Append|| exit 1to ensure themake updatetarget fails immediately on error.🛠️ Proposed fix to ensure fast failure
`@for` c in $(CRDS); do \ curl -fsSL "https://raw.githubusercontent.com/cozystack/etcd-operator/$(ETCD_OPERATOR_REF)/charts/etcd-operator/crd-bases/etcd-operator.cozystack.io_$$c.yaml" \ | awk '/^ controller-gen.kubebuilder.io\/version:/{print; print " helm.sh/resource-policy: keep"; next} {print}' \ - > templates/$$c.yaml; \ + > templates/$$c.yaml || exit 1; \ done🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@packages/system/etcd-operator-crds/Makefile` around lines 17 - 21, Update the CRD download loop in the Makefile’s update target so a failed curl command immediately exits with a nonzero status, preventing awk from writing an empty or incomplete template and ensuring make reports the failure.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Nitpick comments:
In `@packages/system/etcd-operator-crds/Makefile`:
- Around line 17-21: Update the CRD download loop in the Makefile’s update
target so a failed curl command immediately exits with a nonzero status,
preventing awk from writing an empty or incomplete template and ensuring make
reports the failure.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Path: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
Run ID: 4de409eb-a339-4911-a6e8-41237ecd8528
📒 Files selected for processing (5)
packages/system/etcd-operator-crds/Makefilepackages/system/etcd-operator-crds/templates/etcdmembers.yamlpackages/system/etcd-operator/Chart.yamlpackages/system/etcd-operator/Makefilepackages/system/etcd-operator/tests/deployment_test.yaml
IvanHunters
left a comment
There was a problem hiding this comment.
LGTM with non-blocking notes
The bump is mechanically correct and confirmed end-to-end. git compare v0.5.2...v0.5.3 contains exactly #340, #341, #342 and nothing else; the S3
checksum fix from #342 (S3 RequestChecksumCalculation=WhenRequired plus the
TestUploadS3StreamMultipartNoChecksumTrailer regression test) is really in the
release. No tag/digest desync: the etcd-operator image resolves from
Chart.yaml appVersion: v0.5.3 (values.yaml keeps tag: ""), and the only
sha256: pin in values.yaml belongs to the unrelated hook image. The vendored
CRD changes are byte-identical to upstream crd-bases at v0.5.3, and the PR
incidentally fixes a pre-existing vendoring drift (peerAutoTLS). No
CRITICAL/MAJOR.
MINOR
-
packages/system/etcd-operator-crds/Makefile:17-21—curl … | awk … > filedoes not detect a curl failure. The pipe's exit code comes from the
last stage (awk), notcurl, and neither the Makefile norhack/package.mk
setspipefail. On a future bump, a 404 / network error / upstream path
rename would silently write an empty or truncated CRD template while
make updatestill returns success. Reproduced directly: pointing the recipe
at a non-existent path returned a 404 on stderr, a 0-byte file, and exit 0. No
impact on this PR (the regenerated output is byte-identical to what is
committed). Fix: addset -e -o pipefail;before the loop, or|| exit 1at
the end. -
PR body is missing the
release-noteblock and the downstream-repositories
checklist required by.github/pull_request_template.md:49-57. Release-note
tooling cannot extract anything, and there is no record that downstream impact
(e.g. versions incozystack/website) was checked.
Review of #3403 noted the `curl … | awk > file` recipe swallowed curl failures: the pipe's exit status is awk's, and neither the Makefile nor hack/package.mk sets pipefail, so a 404 / network error / upstream path rename on a future bump would write an empty/truncated CRD template and still exit 0. Fetch to a temp file under `set -e` (curl -f already exits non-zero on HTTP error), then awk from it — shell-agnostic (no pipefail, which dash lacks). Verified: the regenerated templates are byte-identical to the committed ones, and a bad ref now exits non-zero leaving no template files instead of silently writing empties. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> Signed-off-by: Andrey Kolkov <andrey.kolkov@aenix.io>
IvanHunters
left a comment
There was a problem hiding this comment.
Reviewed as a vendored first-party bump. LGTM.
- CRD changes are strictly additive and backward-compatible:
etcdmembersstays on a single served+storage version (v1alpha2), only optional fields (spec...peerAutoTLS,status.version) and a printer column were added, so existing stored objects remain valid and no conversion/migration is needed. - No RBAC drift: diffing the upstream chart
templates/rbac.yamlbetween v0.5.2 and v0.5.3 shows them byte-for-byte identical. - Vendored CRDs match upstream v0.5.3 byte-for-byte (modulo the injected
helm.sh/resource-policy: keep, which also protects them from GC on uninstall). - Changelog v0.5.2..v0.5.3 is exactly observed-versions, optional
--watch-namespace(not set by the chart), and the S3 checksum fix. No hidden breaking changes. helm unittestpasses (18/18); the rewrittenmake updatetarget is a real improvement (fail-loud viaset -e+ temp file instead of a silent pipe).
Non-blocking: the S3 fix behaviour on non-AWS backends can't be validated by static review (covered by the author's e2e run + upstream tests). The unittest asserts a literal image tag, which would break if the release process ever rewrites first-party tags to vX.Y.Z@sha256:... (pre-existing, not introduced here).
What this PR does
Bumps the etcd-operator to v0.5.3, which carries the S3 request-checksum fix (cozystack/etcd-operator#342).
git compare v0.5.2...v0.5.3is exactly #340, #341, #342.Why: scheduled etcd snapshots to non-AWS S3-compatible backends (Ceph RGW confirmed) fail at upload. Since early 2025
aws-sdk-go-v2defaultsRequestChecksumCalculationtoWhenSupported, which stamps a CRC32 on every upload; over HTTPS a multipart part rides it asx-amz-content-sha256: STREAMING-UNSIGNED-PAYLOAD-TRAILER, and RGW rejects it with400 InvalidArgument. v0.5.3 setsWhenRequiredon both the S3 client and the transfer manager, so multipart uploads (>5 MiB — every real etcd snapshot) carry no checksum trailer.Changes:
system/etcd-operator—appVersionv0.5.2 → v0.5.3 (image tag follows AppVersion;values.yamlkeepstag: ""), bumpETCD_OPERATOR_REF, update deployment unittest expectations.system/etcd-operator-crds— re-vendor CRDs from v0.5.3.etcdmembersgains the additive fix Kamaji OOM #340status.versionfield + Running printer column and picks up thepeerAutoTLSspec field the vendored copy was already missing (all additive, backward-compatible;etcdclusters/etcdsnapshotsunchanged). Fixes the stalemake update(upstream has noconfig/crdkustomization — CRDs live incharts/etcd-operator/crd-bases) and makes it fail loudly on a fetch error (temp file underset -e, not a pipe).Verification:
helm unittest18/18 andhelm templategreen on both packages; regenerated CRDs are byte-identical to upstreamcrd-basesat v0.5.3. End-to-end on a live Ceph RGW backend (freedom-portal-stage): the v0.5.2 (client-only) agent fails a multipart snapshot upload with the 400; v0.5.3 uploads an 11 MiB multipart snapshot successfully, and the operator-driven CronJob→EtcdSnapshot path reachesComplete.Downstream repositories
Walked the trigger map in
docs/agents/contributing.mdfile-by-file against the diff (packages/system/etcd-operator{,-crds}/**only — a component version bump + additive CRD re-vendor). Nothing matches: not anapps//extra/package add/rename/remove, nocore/platformvalues, no variant/bundle, no platform component add/remove, nohack/layout or shared-tooling change, and the provider does not type theetcd-operator.cozystack.ioCRDs (and the change is additive/opaque regardless).Release note
Summary by CodeRabbit
New Features
EtcdMember(including a “Running” status column).peerAutoTLSsupport toEtcdMemberfor operator-managed peer TLS behavior.Updates
Tests