fix(objectstorage-controller): propagate Bucket readiness to BucketClaim by lexfrei · Pull Request #2792 · cozystack/cozystack

Aleksei Sviridkin (lexfrei) · 2026-06-02T22:50:26Z

What this PR does

The vendored COSI objectstorage-controller (built from upstream v0.2.2) leaves dynamically-provisioned buckets without credentials.

In the dynamic-provisioning path, provisionBucketClaimOperation sets BucketClaim.status.bucketName but hardcodes bucketReady=false and never re-reads the Bucket. The controller does not watch Bucket objects, so the readiness transition the sidecar performs after DriverCreateBucket (Bucket.status.bucketReady false→true) is never propagated back to the BucketClaim. Each periodic resync re-enters the same branch (Buckets().Create returns AlreadyExists, which is ignored) and re-sets bucketReady=false. As a result BucketClaim.status.bucketReady stays false forever, the sidecar refuses to grant the BucketAccess ("BucketAccess can't be granted to Bucket not in Ready state"), and the credentials secret is never created — even though the bucket exists in the backend and the Bucket CR already reports bucketReady: true.

This adds a vendored patch that re-reads the live Bucket after create and propagates its readiness onto the BucketClaim, so the existing periodic resync converges the claim to ready and access can be granted.

The fix mirrors what the rewritten upstream controller already does on main (claim.Status.ReadyToUse = bucket.Status.ReadyToUse). Upstream main is a v1alpha2 rewrite and the maintained release-0.2 branch still carries the bug, so this stays a vendored patch against v0.2.2 until the controller is bumped to a release that includes the fix.

Verified: reproduced the stuck-false claim with a unit test against the upstream v0.2.2 source and confirmed the patch resolves it, existing controller tests pass, the patch applies cleanly to v0.2.2, and the controller image builds.

Release note

fix(objectstorage-controller): propagate Bucket readiness to the BucketClaim so dynamically-provisioned buckets receive credentials instead of getting stuck without a granted BucketAccess

Summary by CodeRabbit

Bug Fixes
- Fixed an issue where bucket readiness status was incorrectly reported when a bucket already existed. The status now accurately reflects the actual state of the existing bucket instead of being unconditionally set to not ready.

The vendored COSI controller (v0.2.2) sets only BucketClaim.status.bucketName in the dynamic-provisioning path and hardcodes bucketReady=false, never re-reading the Bucket afterwards. The controller does not watch Buckets, so the readiness transition the sidecar performs (false->true) is never reflected on the BucketClaim: bucketReady stays false forever and BucketAccess is never granted, leaving provisioned buckets without credentials. Re-read the live Bucket after create and propagate its readiness, so the periodic resync converges the BucketClaim to ready. This matches the behavior the rewritten upstream controller already has on its main branch. Assisted-By: Claude <[email protected]> Signed-off-by: Aleksei Sviridkin <[email protected]>

gemini-code-assist · 2026-06-02T22:50:30Z

Note

Gemini is unable to generate a summary for this pull request due to the file types involved not being currently supported.

coderabbitai · 2026-06-02T22:50:39Z

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

Run ID: 8cd85afa-bf1f-4f53-837c-5d5a54fd943d

📥 Commits

Reviewing files that changed from the base of the PR and between 26da871 and ed20a43.

📒 Files selected for processing (1)

packages/system/objectstorage-controller/images/objectstorage/patches/92-bucketclaim-propagate-ready.diff

📝 Walkthrough

Walkthrough

This PR updates the provisionBucketClaimOperation function to properly propagate the BucketReady status from an existing Bucket object to a BucketClaim, replacing the previous behavior of unconditionally setting it to false. The change includes error handling for API read failures.

Changes

BucketReady Status Propagation

Layer / File(s)	Summary
Live bucket status propagation `packages/system/objectstorage-controller/images/objectstorage/patches/92-bucketclaim-propagate-ready.diff`	When a bucket already exists, the controller fetches the current Bucket object from the Kubernetes API and copies its BucketReady status to the BucketClaim. If the read fails, a warning is recorded and the reconcile operation fails.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~5 minutes

Poem

A bucket once silent now speaks its mind,
Its readiness shared with the claim behind,
No longer false, but truthfully known—
The status now grows from what's been shown. 🐇✨

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title clearly and specifically describes the main fix: propagating Bucket readiness status to BucketClaim, which aligns with the primary objective of the changeset.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

🧪 Generate unit tests (beta)

Create PR with unit tests
Commit unit tests in branch fix/cosi-bucketclaim-propagate-ready

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.

❤️ Share

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

Andrei Kvapil (kvaps)

Verified the patch against the actual upstream source: it applies cleanly to v0.2.2 on top of the existing 91-bucketaccess-conflict-retry.diff in the Dockerfile's glob order, and the semantics check out — the fresh-create path is unchanged (a just-created Bucket is bucketReady=false anyway), while the AlreadyExists path now picks up the readiness the sidecar set in the meantime. Convergence is fast: the controller runtime's default resync is 30s, and once the claim is ready provisionBucketClaimOperation early-returns, so there's no churn after convergence. The fix also mirrors what upstream main does (claim.Status.ReadyToUse = bucket.Status.ReadyToUse), so the vendored patch won't fight a future controller bump.

github-actions · 2026-06-05T08:10:40Z

Successfully created backport PR for release-1.4:

[Backport release-1.4] fix(objectstorage-controller): propagate Bucket readiness to BucketClaim #2828

…t readiness to BucketClaim (#2828) # Description Backport of #2792 to `release-1.4`.

Aleksei Sviridkin (lexfrei) requested a review from Andrei Kvapil (kvaps) as a code owner June 2, 2026 22:50

Aleksei Sviridkin (lexfrei) added the kind/backport Categorizes issue or PR as requiring a backport to the current release line label Jun 2, 2026

Aleksei Sviridkin (lexfrei) requested review from IvanHunters, Andrey Kolkov (androndo), Timofei Larkin (lllamnyp), myasnikovdaniil and Kirill Ilin (sircthulhu) as code owners June 2, 2026 22:50

github-actions Bot added area/uncategorized PR auto-labeler could not map title scope to a known area/*; please review kind/bug Categorizes issue or PR as related to a bug size/S This PR changes 10-29 lines, ignoring generated files labels Jun 2, 2026

dosubot Bot added the area/storage Issues or PRs related to storage (linstor, seaweedfs, bucket, velero, harbor) label Jun 2, 2026

Aleksei Sviridkin (lexfrei) self-assigned this Jun 3, 2026

Andrei Kvapil (kvaps) approved these changes Jun 4, 2026

View reviewed changes

Aleksei Sviridkin (lexfrei) merged commit 67b406f into main Jun 5, 2026
14 checks passed

Aleksei Sviridkin (lexfrei) deleted the fix/cosi-bucketclaim-propagate-ready branch June 5, 2026 08:10

github-actions Bot mentioned this pull request Jun 5, 2026

[Backport release-1.4] fix(objectstorage-controller): propagate Bucket readiness to BucketClaim #2828

Merged

myasnikovdaniil added a commit that referenced this pull request Jun 5, 2026

[Backport release-1.4] fix(objectstorage-controller): propagate Bucke…

05eeb09

…t readiness to BucketClaim (#2828) # Description Backport of #2792 to `release-1.4`.

coderabbitai Bot mentioned this pull request Jun 24, 2026

fix(objectstorage-controller): converge BucketClaim readiness and speed up COSI provisioner failover #3034

Merged

Aleksei Sviridkin (lexfrei) mentioned this pull request Jun 29, 2026

objectstorage-controller: merged BucketClaim requeue fix (#3034) is not deployed — pinned digest predates it (harbor E2E flake + systemic gap) #3143

Closed

Navigation Menu

Repository navigation

fix(objectstorage-controller): propagate Bucket readiness to BucketClaim - #2792

fix(objectstorage-controller): propagate Bucket readiness to BucketClaim#2792
Aleksei Sviridkin (lexfrei) merged 1 commit into
mainfrom
fix/cosi-bucketclaim-propagate-ready

Aleksei Sviridkin (lexfrei) commented Jun 2, 2026 •

edited by coderabbitai Bot

Loading

Uh oh!

gemini-code-assist Bot commented Jun 2, 2026

Uh oh!

coderabbitai Bot commented Jun 2, 2026 •

edited

Loading

Walkthrough

Changes

Estimated code review effort

Poem

Uh oh!

Andrei Kvapil (kvaps) left a comment

Uh oh!

Uh oh!

github-actions Bot commented Jun 5, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Conversation

Aleksei Sviridkin (lexfrei) commented Jun 2, 2026 • edited by coderabbitai Bot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

What this PR does

Release note

Summary by CodeRabbit

Uh oh!

gemini-code-assist Bot commented Jun 2, 2026

Uh oh!

coderabbitai Bot commented Jun 2, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Walkthrough

Changes

Estimated code review effort

Poem

Uh oh!

Andrei Kvapil (kvaps) left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

github-actions Bot commented Jun 5, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Aleksei Sviridkin (lexfrei) commented Jun 2, 2026 •

edited by coderabbitai Bot

Loading

coderabbitai Bot commented Jun 2, 2026 •

edited

Loading