Skip to main content

Operator releases

ghcr.io/miropshq/mirops/operator · source: miropshq/mirops

0.2.1 — Sep 28, 2026​

  • Every report is .mirops — a ClusterMirror's report is now <name>.mirops, like an UpgradeAnalysis's and as the CRD documents; 0.2.0 wrote <name>.mirror. The report's kind says which resource wrote it.
  • The reports service tells them apart with ?kind= — /reports/<name>.mirops?kind=ClusterMirror serves a mirror's report; without it, the name is an UpgradeAnalysis's.
Upgrading from 0.2.0

Update the Web UI to 0.3.1: the 0.3.0 plugin asks for <name>.mirror, which 0.2.1 no longer serves. Pipelines that read a mirror report from a bucket keep reading <name>.mirror until you point MIROPS_SOURCE at <name>.mirops — the operator writes the new name from its first rebuild, and never deletes the old object. A mirror with its own key / blobName keeps that name.

0.2.0 — Sep 26, 2026​

The mirror now runs all the time, and upgrade analysis is a switch you turn on when an upgrade is coming.

  • ClusterMirror — a new cluster-scoped CRD. The operator rebuilds the mirror every refresh.interval (default 5m), on a spec change, or on the mirops.io/refresh annotation, and publishes the cluster's current risk: status.components, edges, atRisk, byNamespace, lastSync, syncError.
  • The mirror report (<name>.mirror) — summary, at-risk components with their dependents and where their risk comes from (inheritedFrom), per-namespace risk, live problems, add-ons, workloads, the graph, and upgrade: whether upgrade analysis is on, plus an index of every UpgradeAnalysis.
  • Report destinations for the mirror — spec.source accepts file, s3, blob or pvc, like an UpgradeAnalysis. The report is overwritten on every rebuild; the reports server reads remote ones back.
  • Upgrade analysis is opt-in — the UpgradeAnalysis controller runs only with MIROPS_UPGRADE_ENABLED=true (Helm upgrade.enabled). One pod runs both controllers.
  • The upgrade report focuses on the upgrade — it gains kind and upgradeImpact (for each add-on the target version breaks, everything that depends on it), and keeps its 0.1.0 fields.
  • No resources created for you — the operator creates no ClusterMirror; you create one after installing, like an UpgradeAnalysis.
  • Embedded compatibility matrix: v2026.09.03 — 18 common add-ons, with rules up to Kubernetes 1.36.
Upgrading from 0.1.0

Upgrade analysis is now off by default. If you run UpgradeAnalyses, upgrade the chart with --set upgrade.enabled=true. Then create a ClusterMirror — see Create a ClusterMirror. The new operator installs the ClusterMirror CRD itself.

0.1.0 — Sep 20, 2026​

The first public release.

  • The logical mirror + upgrade analysis — collect a cluster snapshot, build the dependency graph, propagate risk, and produce a readiness score with a deterministic verdict (SAFE / WARNING / CRITICAL).
  • Add-on compatibility — a vendor-verified matrix covering common add-ons, embedded in the operator and overridable via ConfigMap.
  • Dependency graph & per-namespace risk — visible blast radius, not just a number.
  • Optional AI scoring & remediation — Anthropic/OpenAI, blended into the gauge only (never the gate), with AI-proposed RemediationPlan actions gated on approval.
  • Report destinations — file, S3, Azure Blob, and PVC, written as .mirops (JSON content).
  • The operator installs its own CRDs at startup. Embedded compatibility matrix: v2026.09.03.