Report destinations
spec.source selects where the operator writes the report. The block is the same on a ClusterMirror (rewritten on every rebuild) and an UpgradeAnalysis — both write <name>.mirops; drop any of these into either.
file (default)
Written to the pod and served over HTTP (:8084). Lost when the pod restarts; a mirror's report is also missing for a few seconds on a leader change, until the next rebuild.
source:
type: file
path: "" # optional basename; defaults to <name>.mirops
s3
No local replica — written to S3 and read back on demand. Omit credentialsSecret to use IRSA.
source:
type: s3
bucket: my-reports
region: us-east-1
key: clusters/prod.mirops # you own the name; empty → <name>.mirops
credentialsSecret: aws-creds # optional; keys: AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY
blob (Azure)
No local replica. Omit credentialsSecret to use Workload / Managed Identity.
source:
type: blob
accountName: mystorage
containerName: reports
blobName: prod.mirops # you own the name; empty → <name>.mirops
credentialsSecret: azure-creds # optional; keys: AZURE_CLIENT_ID, AZURE_CLIENT_SECRET, AZURE_TENANT_ID
pvc (in-cluster persistent storage)
Like file, but persistent — the report survives pod restarts, with no cloud object storage needed (handy on-prem). Enable the volume with reportPVC.enabled=true in the Helm chart. Read it in-cluster: the operator's HTTP endpoint, or by mounting the same PVC.
source:
type: pvc
path: /reports # directory on the mounted volume; report → <name>.mirops
Credentials
credentialsSecret is optional — leave it empty to use IRSA (S3) or Workload/Managed Identity (Azure); set it to a Secret in the operator's namespace with static keys otherwise.
Naming & content
Every report is .mirops, for every destination, local file included. The content is JSON (uploaded as application/json) whose top-level kind (ClusterMirror / UpgradeAnalysis) says which resource wrote it. The extension keeps reports distinct from config files in the same destination; a mirror and an analysis writing to the same destination need different names.
Failure reporting
A write/read failure is recorded on the CR — status.reportState (written/failed), status.reportError, and status.reportLocation, plus status.syncError on a ClusterMirror — so it surfaces in kubectl describe and the UI. Deleting the CR never deletes the object from S3/Blob/PVC. See reports.