minio/helm/silo/Chart.yaml at 6613c2a3cb0d00b92063a5cf585a39881320edc9 - minio - git.stelm.me

astelm/minio

mirror of https://github.com/pgsty/minio.git synced 2026-08-10 00:03:29 +03:00

Files

T

Feng Ruohang e071bb77e4 build(helm): replace the minio chart with a silo chart that preserves identity

helm/minio becomes helm/silo: chart name silo, version 6.0.0 -> 7.0.0, the
MinIO wordmark icon replaced with the project's own, image.repository and
mcImage.repository pointing at pgsty/silo, and the container command changed to
silo. User-visible titles, comments and documentation links are rebranded. The
MINIO_* environment variables and every existing values key are kept - the
first Silo chart is a rename, not a values-schema migration.

The hard problem is that a chart rename normally rewrites Kubernetes resource
identity, and a StatefulSet's selector and volumeClaimTemplate are immutable.
An existing release upgraded carelessly would either fail or orphan its PVCs.
Two things address that:

- Templates no longer derive the container name from .Chart.Name. It comes from
  a helper, so nameOverride can pin it, which means an existing release can be
  upgraded with nameOverride=minio, fullnameOverride=<existing-fullname> and
  serviceAccount.name=minio-sa and render byte-stable identity while switching
  chart and image.

- helm-migration-guard and verify-helm-migration.sh make that a gate rather
  than a documented hope. The script lints the chart, renders it in distributed
  and standalone modes plus the optional templates, then renders the legacy
  chart from a pinned commit and the new chart with those three overrides and
  compares resource identity. The guard additionally rejects any rendered
  container still pulling pgsty/minio or invoking /usr/bin/minio. It runs
  through a pinned alpine/helm image when helm is not installed locally, so the
  gate does not depend on the developer's machine. Currently green over 7
  compared resources.

Rollback is asymmetric and the README says so: the old chart with the new image
survives via the entrypoint argv shim, but the new chart with an old MinIO
image does not, because `silo server` is not a command that binary knows. Only
`helm rollback` is supported, never an image-only downgrade.

Not addressed here: the default image tag is pgsty/silo:RELEASE.2026-08-04T00-00-00Z,
which does not exist yet. The chart must not be published until the first Silo
image is pushed.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

2026-08-06 08:48:17 +08:00

19 lines

365 B

YAML

Raw Blame History

 apiVersion: v1
 description: S3-Interface Libre Object Storage
 name: silo
 version: 7.0.0
 appVersion: RELEASE.2026-08-04T00-00-00Z
 keywords:
   - silo
   - storage
   - object-storage
   - s3
   - cluster
 home: https://silo.pgsty.com/
 icon: https://silo.pgsty.com/img/silo.svg
 sources:
 - https://github.com/pgsty/minio
 maintainers:
 - name: Pigsty
   url: https://pigsty.io