Bucket deletion blocked by "bucket not empty" retries only on exponential backoff, with no way to trigger a retry short of a spec change
まだ誰も着手していません。
評価
- 難易度
- 4/5
- 見積もり時間
- 3〜5日
- 初心者へのやさしさ
- 65/100
- issue の種類
- バグ
- 明瞭さ
- おおむね明確
- 活発さ
- 活発
- 技術スタック
- go, kubernetes
- 領域
- backend, devops, infrastructure
調査の方向性
Start with the update predicate in internal/controller/bucket/controller.go, then trace finalizer errors through internal/controller/bucket/finalizer.go and internal/helpers/controller.go. Reproduce the failed deletion and observe retry timing and update filtering. Done means recoverable bucket-deletion failures retry predictably after the bucket is emptied, with an actionable condition and consistent behavior across the named finalizers.
索引モデルが issue の本文から書いたものです。
説明
What happens
With bucketDeletionEnabled: true on the S3Instance, deleting a Bucket whose S3 bucket still holds objects fails, as expected:
Bucket deletion has failed: The bucket you tried to delete is not empty
The CR keeps its deletionTimestamp and the s3.onyxia.sh/finalizer. After the user empties the bucket, the obvious expectation is that the operator notices soon and finishes the deletion. It doesn't. There are two separate problems:
- Retries fall back to controller-runtime's default exponential backoff, capped at 1000 s. In our case the attempts came at 16:48:45, 16:49:26, 16:50:07 and 16:59:40 UTC, and the gaps keep growing to about 16.7 minutes. The only feedback is a
Reconciled=False/DeletionFailurecondition. ItslastTransitionTimerightly stays unchanged, so from outside the Bucket simply looks stuck. - Nothing but a spec change triggers a new attempt. The Bucket controller's event filter drops every update that doesn't change
metadata.generation. Adding or changing an annotation or label does nothing, so the only way to retry now is a meaningless spec edit. That's what people end up doing, and it's not obvious.
Where (v0.12.0, 41b84ba)
internal/controller/bucket/controller.go#L53-L56: theUpdateFuncpredicate reconciles only when the generation changes.internal/controller/bucket/finalizer.go#L39-L55: afinalizeBucketerror goes toSetReconciledCondition(..., DeletionFailure, ..., err).internal/helpers/controller.go#L89: it returnsreconcile.Result{RequeueAfter: requeueAfter}, err. Sinceerris non-nil, controller-runtime ignoresRequeueAfterand applies its rate limiter, so--reconcile-perioddoesn't help here either.
The same pattern appears in the Path, Policy and S3User finalizers.
Reproduce
- Use an S3Instance with
bucketDeletionEnabled: true. - Create a
Bucketand put an object in it. kubectl delete bucket <name>. The deletion fails with "not empty", as expected.- Delete the object.
- Watch the operator logs: the next attempt comes only when the backoff expires, which after a few failures means minutes.
kubectl annotate bucket <name> foo=bardoesn't trigger one; a spec change does.
Suggestions
- Retry a known, recoverable finalizer failure on a short fixed interval. For "bucket not empty", return
ctrl.Result{RequeueAfter: 30 * time.Second}, nil, after setting the condition, instead of returning the error. The retry interval then stays constant and predictable. - Make the condition message actionable. For example: "bucket is not empty; delete its objects (including versions) and the operator will retry".
- Optionally, let deleting resources through the event filter. Reconciling on any update while
deletionTimestampis set would make a label or annotation change a supported manual trigger. (predicate.Or(predicate.GenerationChangedPredicate{}, predicate.AnnotationChangedPredicate{})would do the same in general.) - Possibly add an opt-in on the S3Instance to empty a bucket before deleting it, for setups that already treat CR deletion as data deletion. This is a larger design question and could be a separate issue.
Environment: s3-operator v0.12.0 (inseefrlab/s3-operator:v0.12.0, controller-runtime v0.20.1), with Silo (pgsty's MinIO fork, pgsty/silo:RELEASE.2026-09-16T00-00-00Z, s3Provider: minio) behind the S3Instance, on Kubernetes 1.36. The "not empty" error is the S3 server's standard BucketNotEmpty response to DeleteBucket, so this should reproduce the same way on upstream MinIO.
- 主要言語
- Go
- スター
- 66
- フォーク
- 16
- PR マージ指標
- 30日以内にマージされた PR はありません
環境構築
このプロジェクトの開発コンテナを、あなたの GitHub アカウントでブラウザ上に起動します。
- Dockerfile または Docker Compose ファイルあり
- プルリクエストのテンプレートなし
- コントリビューションガイドなし
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
InseeFrLab/s3-operator のほかの issue
-
Existence checks depend on MinIO error codes; decide policy/user existence from list calls insteadオープン
難易度 4/5 3〜5日 初心者へのやさしさ 72/100
InseeFrLab/s3-operator#144 · コメント 2 件 ·
-
難易度 3/5 1〜2日 初心者へのやさしさ 45/100
InseeFrLab/s3-operator#136 ·
-
難易度 4/5 3〜5日 初心者へのやさしさ 48/100
InseeFrLab/s3-operator#135 ·
-
難易度 2/5 1〜3時間 初心者へのやさしさ 58/100
InseeFrLab/s3-operator#113 ·
-
難易度 5/5 1週間以上 初心者へのやさしさ 30/100
InseeFrLab/s3-operator#112 · リアクション 1 件 ·
InseeFrLab/s3-operator の issue をすべて見る
似ている issue
-
難易度 2/5 1〜3時間 初心者へのやさしさ 78/100
-
難易度 2/5 1〜3時間 初心者へのやさしさ 67/100
adrianbrad/queue#92 ·
-
難易度 2/5 1〜3時間 初心者へのやさしさ 78/100
-
agent-ready area:skills
難易度 2/5 1〜3時間 初心者へのやさしさ 75/100
jmbarzee/temporal-architect#444 ·
メンテナーはふだん 1 日以内に返信
-
enhancement needs:sonnet ready-for-agent
難易度 2/5 1〜3時間 初心者へのやさしさ 78/100
メンテナーはふだん 1 日以内に返信