## Description ### Background When the minio-instance chart is deployed as a subchart within a parent package (e.g., Mimir, Loki), the MinIO Operator is responsible for provisioning buckets declared in the Tenant CR's \`buckets\` field. However, the MinIO Operator's reconciliation loop can be blocked before reaching the bucket provisioning step. The specific failure mode observed in Mimir: the rollout-operator registers a \`ValidatingWebhookConfiguration\` that intercepts all StatefulSet UPDATE operations in the package namespace. The MinIO Operator triggers a StatefulSet update during its reconciliation loop; if the webhook is unreachable (e.g., in k3d environments due to cross-node routing), the operator receives a 502 and retries indefinitely, never advancing to bucket creation. This is not limited to Mimir as this will affect Loki since both charts: 1. Deploys a namespace-scoped webhook that intercepts StatefulSet UPDATE operations 2. Deploys a MinIO Tenant in the same namespace Currently this applies to **Mimir** and **Loki**, both of which use the rollout-operator alongside a minio-instance subchart. ### Problem The \`buckets\` field in the MinIO Tenant CR is the intended declarative mechanism for bucket provisioning, but it is not reliable when the MinIO Operator reconciliation loop is blocked. Each package that uses minio-instance currently has to implement its own workaround. ### Proposed Solution Add a bucket initialization Job to the minio-instance chart that: - Runs as a \`post-install,post-upgrade\` Helm hook - Waits for MinIO to be healthy via \`/minio/health/live\` - Creates each bucket declared in \`.Values.upstream.tenant.buckets\` using the S3 API (curl with \`--aws-sigv4\`) - Treats HTTP 200 and 409 (BucketAlreadyOwnedByYou) as success, making it fully idempotent - Is gated through the values.yaml This centralizes the workaround in minio-instance so that Mimir, Loki, and any future package using minio-instance as a subchart get bucket initialization automatically without duplicating the logic per package. ## Known Limitations ### Shared Namespace with MinIO — rollout-operator Webhook Conflict Mimir deploys the rollout-operator as a sub-chart, which installs admission webhooks (`no-downscale`, `prepare-downscale`, `pod-eviction`) that intercept `StatefulSet` UPDATE operations within the release namespace. These webhooks are scoped via `namespaceSelector` to the Mimir namespace but have no `objectSelector`, meaning they intercept **all** StatefulSet UPDATEs in the namespace regardless of which operator owns them. **Impact when MinIO shares the Mimir namespace:** - The rollout-operator webhooks intercept MinIO Operator reconciliation calls - With `failurePolicy: Fail` (default), any webhook timeout or rejection blocks the MinIO Operator from reconciling the `Tenant` CR - Affects initial bucket creation and any subsequent `Tenant` changes (scaling, resource updates, image changes) **Recommended configuration:** Deploy Mimir and MinIO in separate namespaces. This is the only fully supported configuration to avoid this conflict. **If a shared namespace is required:** - The `bucket-init` Job in this MR mitigates the initial bucket creation problem - Subsequent `Tenant` spec changes that require StatefulSet UPDATEs may silently fail there is no BB-level workaround for this - A proper fix requires the upstream rollout-operator to expose `objectSelector` as a configurable value so webhooks can be scoped to Mimir-owned StatefulSets only ## Acceptance Criteria - [ ] A \`post-install,post-upgrade\` Helm hook Job is added to the minio-instance chart that creates all buckets declared in \`.Values.upstream.tenant.buckets\` - [ ] The Job is only rendered when flag in values.yaml is enabled - [ ] The Job waits for MinIO health (\`/minio/health/live\`) before attempting bucket creation, retrying until MinIO is ready - [ ] Bucket creation uses the S3 API with AWS Signature V4 (\`--aws-sigv4\`) and credentials from \`.Values.upstream.tenant.configSecret\` - [ ] HTTP 409 (BucketAlreadyOwnedByYou) is treated as success so the Job is safe on upgrades when buckets already exist - [ ] The Job uses the \`registry1.dso.mil/ironbank/big-bang/base\` image and meets BB hardening standards (non-root, read-only filesystem, dropped capabilities, seccomp RuntimeDefault) - [ ] CHANGELOG.md is updated