[bucket] Fix s3manager endpoint mismatch with COSI credentials#2211
[bucket] Fix s3manager endpoint mismatch with COSI credentials#2211
Conversation
…Info The deployment template was constructing the S3 endpoint from the tenant's namespace host (e.g. s3.freedom.infra.example.com), while COSI credentials are issued for the actual SeaweedFS endpoint (e.g. s3.infra.example.com). This mismatch caused 'invalid credentials' errors when users tried to log in with valid credentials from the bucket secret. Now the endpoint is resolved from BucketInfo (same source as credentials), with a fallback to the constructed namespace host for first-time deploys before BucketAccess secrets are created. Signed-off-by: IvanHunters <[email protected]>
IvanHunters
requested review from
androndo,
kvaps,
lexfrei,
lllamnyp and
sircthulhu
as code owners
dosubot
bot
added
the
size:S
Summary of ChangesHello, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed! This pull request resolves a critical issue where the s3manager UI deployment failed to authenticate due to a mismatch between its assumed S3 endpoint and the actual endpoint provided by COSI credentials. By dynamically extracting the correct S3 endpoint from the BucketInfo within the BucketAccess secret, the s3manager now connects to the appropriate S3 service, eliminating "invalid credentials" errors and ensuring reliable operation. A fallback mechanism is also included for initial deployments. Highlights
🧠 New Feature in Public Preview: You can now enable Memory to help Gemini Code Assist learn from your team's feedback. This makes future code reviews more consistent and personalized to your project's style. Click here to enable Memory in your admin console. Changelog
Using Gemini Code AssistThe full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips. Invoking Gemini You can request assistance from Gemini at any point by creating a comment using either
Customization To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a Limitations & Feedback Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for GitHub and other Google products, sign up here. You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension. Footnotes
|
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (1)
📝 WalkthroughWalkthroughThe deployment template now sources the S3 endpoint dynamically from per-user secrets instead of using a hard-coded value. The template iterates over users, retrieves their associated Secrets, decodes the BucketInfo, extracts the endpoint, removes the "https://" prefix, and assigns it to the ENDPOINT environment variable, with a fallback to the original template value if no secret exists. Changes
Estimated code review effort🎯 2 (Simple) | ⏱️ ~12 minutes Poem
🚥 Pre-merge checks | ✅ 3✅ Passed checks (3 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
📝 Coding Plan
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 Tip CodeRabbit can suggest fixes for GitHub Check annotations.Configure the |
![gemini-code-assist[bot]](proxy.php?url=https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request fixes an issue where the s3manager UI was using a constructed S3 endpoint instead of the one provided by COSI, leading to authentication failures. The change introduces logic to look up an existing user's secret to extract the correct endpoint, with a fallback to the old behavior. My review focuses on making this new logic more robust and efficient by avoiding an unnecessary loop over all users.
| {{- range $name, $user := .Values.users }} | ||
| {{- $secretName := printf "%s-%s" $.Values.bucketName $name }} | ||
| {{- $existingSecret := lookup "v1" "Secret" $.Release.Namespace $secretName }} | ||
| {{- if $existingSecret }} | ||
| {{- $bucketInfo := fromJson (b64dec (index $existingSecret.data "BucketInfo")) }} | ||
| {{- $endpoint = trimPrefix "https://" (index $bucketInfo.spec.secretS3 "endpoint") }} | ||
| {{- end }} | ||
| {{- end }} |
There was a problem hiding this comment.
The current logic iterates through all users and repeatedly overwrites the $endpoint variable. This is inefficient and could lead to non-deterministic behavior if different users' secrets were to contain different endpoints, as map iteration order is not guaranteed. Since the S3 endpoint from COSI should be the same for all users of a bucket, it's more robust and efficient to get the endpoint from just one user secret.
I suggest refactoring this to deterministically pick one user (e.g., the first one alphabetically) and get the endpoint from their secret, avoiding the loop altogether.
{{- with (keys .Values.users | sortAlpha | first) }}
{{- $secretName := printf "%s-%s" $.Values.bucketName . }}
{{- $existingSecret := lookup "v1" "Secret" $.Release.Namespace $secretName }}
{{- if $existingSecret }}
{{- $bucketInfo := fromJson (b64dec (index $existingSecret.data "BucketInfo")) }}
{{- $endpoint = trimPrefix "https://" (index $bucketInfo.spec.secretS3 "endpoint") }}
{{- end }}
{{- end }}
kvaps
added
backport
|
Backport failed for Please cherry-pick the changes locally and resolve any conflicts. git fetch origin release-1.0
git worktree add -d .worktree/backport-2211-to-release-1.0 origin/release-1.0
cd .worktree/backport-2211-to-release-1.0
git switch --create backport-2211-to-release-1.0
git cherry-pick -x f647cfd7b9b339b2dc4aa0078b480239fe30095e |
|
Successfully created backport PR for |
3 participants
What this PR does
Fixes s3manager UI deployment to use the actual S3 endpoint from BucketInfo (COSI) instead of constructing it from the tenant namespace host.
The deployment was using
s3.<tenant>.<cluster-domain>while credentials issued by COSI point to the root-level S3 endpoint. This mismatch caused "invalid credentials" errors on login even with correct credentials from the bucket secret.Falls back to the constructed namespace host on first deploy before BucketAccess secrets exist.
Release note
Summary by CodeRabbit