You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
fix(workloadmonitor): report a bucket's workloads not ready until its claim is provisioned - #5096
A Bucket app reports WorkloadsReady=True while its BucketClaim is never provisioned. On a v1.6.5 cluster a tenant got a BucketClaim for bucket class tenant-root, the root tenant there runs no SeaweedFS, and for three days the claim had no status while the objectstorage controller kept emitting FailedCreateBucket with bucketclasses.objectstorage.k8s.io "tenant-root" not found. The Bucket app showed Ready and WorkloadsReady the whole time.
The WorkloadMonitor controller already writes a Workload per BucketClaim with Operational set from status.bucketReady, but the monitor itself counts only pods. The bucket chart renders its monitor with replicas: 0 and minReplicas: 0, so the monitor stays operational whatever happens to the claim.
The monitor now names every selected BucketClaim that is not provisioned in status.message, sets status.reason to the new BucketClaimNotReady and turns Operational false, the same way it already reports a DataVolume that is not ready. A DataVolume verdict keeps the fields when both apply. BucketClaims are listed on every pass, so a stored BucketClaim verdict is recomputed rather than kept like an unread DataVolume verdict, and it clears once the claim is provisioned. Any monitor whose selector picks a BucketClaim follows its readiness, which is what the Workload objects already say. The Application then shows WorkloadsReady=False with that message and reason. Its Ready condition keeps following the HelmRelease, as pkg/registry/apps/application/rest.go intends.
Three new tests cover a provisioned claim, a claim not provisioned with and without a class, a claim outside the selector, the verdict clearing after provisioning with and without a DataVolume reader, and the DataVolume verdict winning over the BucketClaim one. Against the controller on main the four not-provisioned and clearing cases fail and the rest pass. go test ./internal/controller/... and go vet pass. make generate does not run on my machine, gengo fails to parse the go1.27.1 standard library, so I ran the controller-gen object and crd steps of hack/update-codegen.sh for ./api/v1alpha1/... directly. The deepcopy file is unchanged and the generated WorkloadMonitor CRD matches packages/system/cozystack-controller/definitions/cozystack.io_workloadmonitors.yaml. I have not run the change on a live cluster.
#5083 changes the Workload names of the same BucketClaims and does not touch the monitor status, so the two do not overlap.
Screenshots
Not a UI change.
Downstream repositories
The controller, one exported constant and its tests. No CRD schema, values key, default, telemetry metric or package change, so no trigger map entry applies.
No downstream repository is affected by this change
fix(workloadmonitor): a Bucket app reports WorkloadsReady=False with reason BucketClaimNotReady while its BucketClaim is not provisioned, instead of WorkloadsReady=True.
Summary by CodeRabbit
New Features
Workload monitors now report when a selected bucket claim is not provisioned and mark the monitor as non-operational. Status messages include the bucket class when available and list multiple unprovisioned claims in sorted order.
Bug Fixes
The bucket-claim status clears when the claim is provisioned or no longer selected. When DataVolume information is available, its status takes precedence over the bucket-claim status.
github-actionsBot
added
area/monitoring
Issues or PRs related to the monitoring stack (vlogs, vmstack, grafana, workloadmonitor)
kind/bug
Categorizes issue or PR as related to a bug
size/L
This PR changes 100-499 lines, ignoring generated files
labels
Oct 25, 2026
Reviewing files that changed from the base of the PR and between 9d33037 and e8c8fa3.
You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.
Use the checkbox below for a quick retry:
Trigger review
No actionable comments were generated in the recent review.
Walkthrough
WorkloadMonitor reconciliation now reports selected unprovisioned BucketClaims as non-operational. It records a reason and message, clears them when the claims become ready, and gives a readable DataVolume verdict precedence.
Adds the BucketClaimNotReady reason and a sorted message for unready claims. Reconciliation applies this verdict when no readable DataVolume verdict takes precedence, and clears it when the claims become ready. Tests cover readiness, selector matching, recovery, and DataVolume precedence.
Included review availability: This review used your included allowance. Your plan provides up to 8 included reviews per hour; 6 remain after this review.
europrinter (yankawai)
changed the title
fix(workloadmonitor): keep a bucket not ready until its claim is provisioned
fix(workloadmonitor): report a bucket's workloads not ready until its claim is provisioned
Oct 25, 2026
…isioned
A bucket WorkloadMonitor has no pods and minReplicas 0, so it stayed
operational, and the Bucket app stayed Ready, while its BucketClaim was
never provisioned. A tenant whose nearest S3 ancestor runs no SeaweedFS
gets a claim for a bucket class that does not exist, and the dashboard
showed a ready bucket that was never created.
Assisted-by: LLM
Signed-off-by: Yan Bondarenko <[email protected]>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
area/monitoringIssues or PRs related to the monitoring stack (vlogs, vmstack, grafana, workloadmonitor)kind/bugCategorizes issue or PR as related to a bugsize/LThis PR changes 100-499 lines, ignoring generated files
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
github-actions
Bot
added
area/monitoring
europrinter (yankawai)
changed the title
Aleksei Sviridkin (lexfrei)
left a comment
What this PR does
A Bucket app reports WorkloadsReady=True while its BucketClaim is never provisioned. On a v1.6.5 cluster a tenant got a BucketClaim for bucket class
tenant-root, the root tenant there runs no SeaweedFS, and for three days the claim had no status while the objectstorage controller kept emittingFailedCreateBucketwithbucketclasses.objectstorage.k8s.io "tenant-root" not found. The Bucket app showed Ready and WorkloadsReady the whole time.The WorkloadMonitor controller already writes a Workload per BucketClaim with
Operationalset fromstatus.bucketReady, but the monitor itself counts only pods. The bucket chart renders its monitor withreplicas: 0andminReplicas: 0, so the monitor stays operational whatever happens to the claim.The monitor now names every selected BucketClaim that is not provisioned in
status.message, setsstatus.reasonto the newBucketClaimNotReadyand turnsOperationalfalse, the same way it already reports a DataVolume that is not ready. A DataVolume verdict keeps the fields when both apply. BucketClaims are listed on every pass, so a stored BucketClaim verdict is recomputed rather than kept like an unread DataVolume verdict, and it clears once the claim is provisioned. Any monitor whose selector picks a BucketClaim follows its readiness, which is what the Workload objects already say. The Application then shows WorkloadsReady=False with that message and reason. Its Ready condition keeps following the HelmRelease, aspkg/registry/apps/application/rest.gointends.Three new tests cover a provisioned claim, a claim not provisioned with and without a class, a claim outside the selector, the verdict clearing after provisioning with and without a DataVolume reader, and the DataVolume verdict winning over the BucketClaim one. Against the controller on main the four not-provisioned and clearing cases fail and the rest pass.
go test ./internal/controller/...andgo vetpass.make generatedoes not run on my machine, gengo fails to parse the go1.27.1 standard library, so I ran the controller-genobjectandcrdsteps ofhack/update-codegen.shfor./api/v1alpha1/...directly. The deepcopy file is unchanged and the generated WorkloadMonitor CRD matchespackages/system/cozystack-controller/definitions/cozystack.io_workloadmonitors.yaml. I have not run the change on a live cluster.#5083 changes the Workload names of the same BucketClaims and does not touch the monitor status, so the two do not overlap.
Screenshots
Not a UI change.
Downstream repositories
The controller, one exported constant and its tests. No CRD schema, values key, default, telemetry metric or package change, so no trigger map entry applies.
Release note
Summary by CodeRabbit