fix(clickhouse): scheme the backup S3_ENDPOINT on the system-bucket flow - #3963
Conversation
On the useSystemBucket / cozy-default flow the chart pointed the clickhouse-backup sidecar's S3_ENDPOINT straight at the projected cozy-backups-creds.endpoint, which the backup credentials projector stores as a bare host by design. altinity/clickhouse-backup runs S3_ENDPOINT through the aws-sdk-go-v2 endpoint resolver, which rejects a scheme-less value with "Custom endpoint 's3.host' was not a valid URI", so every backup and restore on the default flow failed (reproduced on a live v1.6.2 cluster). ClickHouse was the only cozy-default app hit by this: the CNPG/etcd/velero strategies get a scheme'd URL from the backupstrategy-controller.endpoint helper, and mariadb/foundationdb deliberately pair a bare host with a TLS flag. Prepend https:// on the useSystemBucket path via a helper env plus $(VAR) expansion (a secretKeyRef value can't be string-interpolated), mirroring the platform's endpoint helper which force-prepends https for the always-TLS external S3 ingress. The legacy and bring-your-own-Secret paths keep reading endpoint verbatim, since that value is tenant-supplied and already carries its own scheme. Signed-off-by: Andrey Kolkov <[email protected]> Co-Authored-By: Claude Opus 4.8 (1M context) <[email protected]>
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (2)
Included review availability: Your plan provides up to 8 included reviews per hour; 6 remain after this review. 📝 WalkthroughWalkthroughThe ClickHouse backup sidecar now constructs the system-bucket endpoint from a secret-provided host. Legacy and BYO-Secret flows continue to read the endpoint directly from their secrets. Helm tests cover both configurations. ChangesClickHouse backup endpoint wiring
Estimated code review effort: 2 (Simple) | ~10 minutes Merge Risk: 🔵 Low · up to The endpoint fix is localized and mergeable with owner awareness that the system-bucket credential reference must remain optional; requiring it could prevent pods from starting before credentials are projected. Suggested reviewers: 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
Full details: Docstring CoverageExplanation No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check. Docstring coverage is scoped to functions touched by this diff. Analyzed 0 functions across 0 files. (2 skipped: 2 unsupported.) ✨ Finishing Touches🧪 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 |
myasnikovdaniil
left a comment
There was a problem hiding this comment.
Scheme fix is correct when projected Secret exists before ClickHouse pod start. Lazy projection lifecycle predates this PR, tracked in #3986.
|
Successfully created backport PR for |
What this PR does
On the default
cozy-default/useSystemBucketbackup flow, the ClickHouse chart pointed theclickhouse-backupsidecar'sS3_ENDPOINTstraight at the projectedcozy-backups-creds.endpoint, which the backup credentials projector stores as a bare host (no scheme) by design.altinity/clickhouse-backuprunsS3_ENDPOINTthrough the aws-sdk-go-v2 endpoint resolver, which rejects a scheme-less value withCustom endpoint 's3.host' was not a valid URI— so every ClickHouse backup and restore on the default flow failed. Reproduced live on a v1.6.2 cluster: acozy-defaultBackupJobagainst auseSystemBucket: trueClickHouse hangs, and the sidecar logsS3 ResolveEndpoint ... was not a valid URI.The fix prepends
https://on theuseSystemBucketpath via a helper env plus$(VAR)expansion (asecretKeyRefvalue can't be string-interpolated), mirroring the platform'sbackupstrategy-controller.endpointhelper which force-prependshttps://for the always-TLS external S3 ingress. The legacy and bring-your-own-Secret paths keep readingendpointverbatim, since that value is tenant-supplied and already carries its own scheme.ClickHouse was the only
cozy-defaultapp hit by this. I audited every default-flow app: the CNPG/postgres, etcd and velero strategies already get a scheme'd URL from the endpoint helper, and mariadb and foundationdb deliberately pair a bare host with a separate TLS flag; mongodb reads a full URL from its own chart values. So this is the single scheme-class fix needed.Not addressed here (separate, non-scheme gaps surfaced during the audit, flagged for follow-up): MongoDB has no
useSystemBucketwiring at all (itscozy-defaultstrategy assumes a manually-configuredbackup.endpointURL+ per-app S3 creds), and FoundationDB's self-signed-CA trust to the operator pod is a known gap.Screenshots
Not applicable (no UI changes).
Downstream repositories
No schema or API change (only a chart template and its helm-unittest).
values.yaml/values.schema.json/ the CRD are untouched, so nothing downstream is affected. Leaving every box unticked per the trigger-map guidance.Release note
Summary by CodeRabbit
Bug Fixes
Tests