Skip to main content
Version: 0.2 · v0.2.1

Create an analysis

UpgradeAnalysis is cluster-scoped — it has no namespace. Only targetVersion is required, and it must be higher than the cluster's version.

Turn upgrade analysis on first

Upgrade analysis is off by default. With it off, an UpgradeAnalysis stays on Analyzing and never finishes. Turn it on in the Helm release:

helm upgrade mirops oci://ghcr.io/miropshq/charts/mirops --namespace mirops \
  --reuse-values --set upgrade.enabled=true

An analysis is about what depends on the target version — add-on compatibility, removed APIs, what would stall a node drain — plus the readiness score and the verdict. For the cluster's current state, look at the ClusterMirror.

The simplest form​

apiVersion: mirops.mirops.io/v1
kind: UpgradeAnalysis
metadata:
  name: to-1-35
spec:
  targetVersion: "1.35"
kubectl apply -f analysis.yaml
kubectl describe upgradeanalysis to-1-35   # decision, score, reason, blockers

A fuller example​

apiVersion: mirops.mirops.io/v1
kind: UpgradeAnalysis
metadata:
  name: to-1-35
spec:
  targetVersion: "1.35"
  scoringProfile: production        # production (strict) | non-production (lenient)
  scope:
    mode: application               # all (default) | application (skip system namespaces)
    excludeNamespaces: [monitoring]
  source:
    type: file                      # file | s3 | blob | pvc
  resync:
    interval: "30m"                 # re-run automatically; empty = run once

See the full field list in the CRD reference.

Re-running an analysis​

  • Change the spec — any edit triggers a fresh analysis.

  • Refresh in place — bump the mirops.io/refresh annotation (this is what the Web UI's Re-analyze button does):

    kubectl annotate upgradeanalysis to-1-35 mirops.io/refresh="$(date +%s)" --overwrite

  • On a schedule — set resync.interval. The operator re-analyzes each interval and skips the AI call when the cluster snapshot hasn't changed.

Choose a report destination​

The default file destination is served over HTTP in-cluster, as <name>.mirops. For durable, shareable reports, use a remote destination (S3/Blob/PVC) — the same source block a ClusterMirror uses.

Next​