Goal
Make the Pigsty MINIO/MIO module provision and operate the SILO fork as its first-class implementation, with a clear migration path for existing MinIO deployments and a complete Metrics V3 observability path.
Why
The current module was designed around upstream MinIO (and later RustFS): package/runtime selection, environment rendering, service management, scrape configuration, Grafana dashboards, and alert rules all inherit that model. SILO gives us control over the server and Console, so the module should expose one coherent contract instead of accumulating one-off overrides.
Today the public configuration still has several coupled assumptions:
- the implementation is selected as
minio or rustfs;
- the scrape path is the MinIO Metrics V2 cluster endpoint;
- the embedded Console is configured with a shared
job="minio" selector but no per-cluster selector;
- bundled dashboards and alert rules query V2 metric names.
Changing only one layer would leave provisioning, Console widgets, dashboards, and alerts inconsistent.
Proposed direction
- Add SILO as a supported runtime and make it the default after the compatibility and upgrade path is documented and tested.
- Keep the established
minio_* inventory API where practical. Treat it as the stable Pigsty module interface rather than forcing a disruptive variable rename.
- Render SILO/Console observability settings as first-class role configuration.
- Scope every time series and Console query with Pigsty identity labels, especially
cls for a MinIO/SILO cluster and ins for an instance.
- Scrape Metrics V3 root metrics and configured bucket metrics with bounded, predictable cardinality.
- Port the shipped Grafana dashboards and VictoriaMetrics alert rules to V3 semantics.
- State explicitly which legacy MinIO/RustFS combinations remain supported and how operators migrate or opt out.
Child issues
Related Console work:
Compatibility decisions required
- Whether
minio_type: silo is introduced first and becomes the default in a later release, or changes in the same release.
- Which old MinIO/RustFS versions remain provisionable and whether they keep a V2 scrape profile.
- Package, binary, service, data-directory, CLI, and environment-file naming during upgrades.
- Whether SILO emits compatibility aliases for any V2 metric names, or Pigsty consumers move directly to native V3 names.
- Upgrade/rollback behavior for an existing distributed cluster; no in-place destructive action should be implicit.
Definition of done
Goal
Make the Pigsty MINIO/MIO module provision and operate the SILO fork as its first-class implementation, with a clear migration path for existing MinIO deployments and a complete Metrics V3 observability path.
Why
The current module was designed around upstream MinIO (and later RustFS): package/runtime selection, environment rendering, service management, scrape configuration, Grafana dashboards, and alert rules all inherit that model. SILO gives us control over the server and Console, so the module should expose one coherent contract instead of accumulating one-off overrides.
Today the public configuration still has several coupled assumptions:
minioorrustfs;job="minio"selector but no per-cluster selector;Changing only one layer would leave provisioning, Console widgets, dashboards, and alerts inconsistent.
Proposed direction
minio_*inventory API where practical. Treat it as the stable Pigsty module interface rather than forcing a disruptive variable rename.clsfor a MinIO/SILO cluster andinsfor an instance.Child issues
Related Console work:
Compatibility decisions required
minio_type: silois introduced first and becomes the default in a later release, or changes in the same release.Definition of done
job,cls, andinslabels and bounded cardinality.