Replace deprecated minio subchart with RustFS

[mgruner]

Closes #398. Last part of the move away from bitnami.

Important

Draft until RustFS 1.0 GA. The subchart is pinned to 1.0.0-rc.5. This branch is meant to be rebased until GA ships, then re-pinned before merge.

Why

MinIO stopped publishing community Helm charts and container images, and the MinIO operator repository was archived in March 2026. The bundled bitnami/minio subchart was already only usable through the bitnamilegacy image workaround.

RustFS is S3-compatible and has an official chart that tracks the project's releases 1:1. The alternative cloudpirates/rustfs chart was evaluated and rejected: it self-describes as ALPHA and pins rustfs:1.0.0-beta.1 from 2026-04-29 while declaring appVersion: 1.0.0, and its config vocabulary (RUSTFS_LOG_LEVEL, RUSTFS_EXTERNAL_ADDRESS, RUSTFS_CORS_*) no longer matches what the current server accepts. We only chose cloudpirates elsewhere where there was no usable official chart.

What changed

• Chart 19.0.0 — breaking for anyone using the optional S3 storage provider.
• zammadConfig.minio → zammadConfig.rustfs; subchart values key minio: → rustfs:.
• The subchart is pinned to single-node mode (its own default is a four-pod erasure-coded cluster), its default ingress is disabled (it would otherwise be created for example.rustfs.com), logs go to stdout instead of a second PVC, and the cluster default StorageClass is used.
• Bucket provisioning. Unlike minio's defaultBuckets, the rustfs chart cannot create buckets, and Zammad never creates one either — Store::Provider::S3 only ever does head_bucket. A new s3-init init container in the zammad-init job creates it through Zammad's own S3 provider, so it cannot drift from S3_URL. No extra image to pin. Controlled by zammadConfig.rustfs.bucketInitialisation (default true), never applied to an external S3 service.
• README: upgrade section plus a data migration runbook. RustFS reads MinIO's on-disk layout and migrates its metadata on first start, so the attachments move as a plain file copy between the two volumes via a Job that mounts both — no S3 client, no data leaving the cluster, and the old volume is only read from, so it stays intact as a rollback path. Object-level copying is documented as a fallback for when both volumes cannot be attached to the same node.

Upgrade hazard worth reviewing closely

The bitnami minio PVC carries no helm.sh/resource-policy, and the chart's default mode is standalone (a plain PVC, not a StatefulSet template). A naive helm upgrade therefore deletes the attachment volume the moment the subchart leaves the release. Step 2 of the runbook annotates the PVC with keep before upgrading — that step is load-bearing.

Conversely, the rustfs chart does set helm.sh/resource-policy: keep, so the new volume now survives an uninstall. That behaviour change is documented.

Verification

• Ran a real rustfs/rustfs:1.0.0-rc.5 container with the chart's exact settings and confirmed the full path via an S3 client (path-style, SigV4, region=zammad): head_bucket → 404, create_bucket, put/get/list all succeed.
• Verified the volume-copy migration end to end: a MinIO volume holding four objects from 512 B to 12 MiB (covering both inline and out-of-line part.N storage) was copied to a pristine rustfs volume, and after adoption every object came back byte-identical with its sha256 matching the object key — which is exactly Zammad's own integrity model. Writes after the adoption work too.
• Confirmed rustfs.replicaCount=0 renders a replicas: 0 Deployment while still creating the PVC, which is what keeps the new volume pristine during phase one.
• helm lint and helm template clean on both CI value sets; kubeconform --strict passes (30 resources default, 40 full).
• The rendered s3-init script passes bash -n and its Ruby body passes ruby -c.
• Name derivation verified for a release name containing rustfs and for rustfs.fullnameOverride.

Before merge

• Re-pin zammad/Chart.yaml to the RustFS 1.0.0 GA release
• Perform a full manual migration test
• Enable the commented-out rustfs source/target blocks in .github/updatecli.yaml
• Re-check rustfs/rustfs#7014 — fixed upstream and released in 1.0.0-rc.5. The runbook now relies on this adoption behaviour, so if it ever regresses again the file copy silently produces an unreadable volume. Worth re-verifying on the GA re-pin.

Follow-up (separate PR, after this one is merged)

• Drop the bitnami entry from .github/ct.yaml chart-repos. It cannot go in this PR: while the target branch still carries 18.x, chart-testing needs that repo to resolve the old chart's minio dependency for the upgrade test. Only once main is on 19.x is it dead weight.

🤖 Generated with Claude Code

[coderabbitai]

Important

Draft PR not reviewed

Draft PRs are not automatically reviewed by default.

• Trigger a manual review

To automatically review draft PRs, update your CodeRabbit configuration:

reviews:
  auto_review:
    drafts: true

---

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

[mgruner]

This comment is not neded.

[mgruner]

Removed in 89ef167.