Skip to content

[Epic] Refactor the MINIO module to use SILO by default #763

Description

@Vonng

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

  1. Whether minio_type: silo is introduced first and becomes the default in a later release, or changes in the same release.
  2. Which old MinIO/RustFS versions remain provisionable and whether they keep a V2 scrape profile.
  3. Package, binary, service, data-directory, CLI, and environment-file naming during upgrades.
  4. Whether SILO emits compatibility aliases for any V2 metric names, or Pigsty consumers move directly to native V3 names.
  5. Upgrade/rollback behavior for an existing distributed cluster; no in-place destructive action should be implicit.

Definition of done

  • Fresh single-node and distributed SILO clusters provision successfully over HTTP and TLS.
  • An existing supported MinIO deployment has a documented, tested migration or compatibility path.
  • Re-running the role is idempotent and check mode does not report avoidable drift.
  • Multiple SILO clusters can share one VictoriaMetrics tenant without Console or dashboard cross-talk.
  • Root and configured-bucket V3 metrics are present with stable job, cls, and ins labels and bounded cardinality.
  • Shipped dashboards render without missing-query panels and alert rules evaluate without errors.
  • Operator documentation covers deployment, migration, monitoring, and rollback.

Metadata

Metadata

Assignees

No one assigned

    Labels

    FEATURENew FeaturesMINIOMINIO RelatedMONITORMonitoring relatedPROVISIONDeploy & Provision Related

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions