What Radar Shows
Control surface: Set image updates one or more regular or init-container images on the Rollout’s pod template or supportedworkloadRef target. Radar reads the current images before editing, rejects stale changes instead of overwriting them, and lets the Rollout controller start the resulting canary or blue-green rollout. A paused Rollout saves the template change but does not start rolling out until it is resumed. Promote, Promote full, Skip step, Retry, and Abort are also available on the Rollout detail page, each gated on a live capability probe (patch rollouts and patch rollouts/status are separate grants). Rollback goes through revision history, with an opt-in “skip canary steps” follow-up for hotfixes.
Rollout visibility: Radar keeps serving readiness separate from transient rollout activity. Resource tables, drawers, full workload views, and Applications show the active step, progress, pause, or failure without marking capacity served by the stable revision as unavailable.
Canary/blueGreen progression: The Rollout detail page renders a connected step timeline - every canary step in declaration order, with the current step highlighted and, for an analysis step, its live AnalysisRun status shown inline alongside a clickable link to the AnalysisTemplate/ClusterAnalysisTemplate it references. A blueGreen Rollout gets an equivalent derived phase list (preview scaled up → pre/post-promotion analysis → awaiting promotion → active cutover), since blueGreen has no steps[] array of its own to render directly.
ReplicaSet progression: A ReplicaSets section lists every revision the Rollout owns (newest first), each with its Current/Stable/Rolling-out role badge, image, replica count, and - expandable per revision - its live pods with ready/phase status. Read-only; rollback stays on the existing revision-history dialog. Built entirely from the same useWorkloadRevisions/useWorkloadPods endpoints already used elsewhere for workload rollback, joined client-side by each pod’s own pod-template-hash label - no new backend endpoint needed for this part.
AnalysisRun history: Beyond the four “currently active” analysis slots (step / background / pre-promotion / post-promotion), an AnalysisRun History section lists the Rollout’s full AnalysisRun history - phase, trigger, and metrics passing/total - via a dedicated GET /api/rollouts/{ns}/{name}/analysisruns endpoint gated on listing AnalysisRuns directly (a separate RBAC grant from the Rollout’s own patch capability).
AnalysisTemplate / ClusterAnalysisTemplate / Experiment: Full detail renderers - metric definitions (provider, interval, count, success/failure conditions) for the templates; templates, duration, and per-template replica/analysis status for Experiment. Reached both directly and via the step-timeline/Analysis-section links above.
Why it’s stuck: InconclusiveAnalysisRun names nothing on its own, so Radar resolves the AnalysisRun the controller recorded and surfaces the deciding metric - its success/failure condition, latest measured value, and message. The same verdict reaches AI agents through the Rollout’s issue field.
Topology: Rollout → active AnalysisRun (uses), labelled by trigger (step / background / pre-promotion / post-promotion). Only the runs the Rollout’s status points at are graphed - historical runs would grow the graph without bound. (The full AnalysisRun history above is a detail-page list, not a topology change - the graph’s “only active runs” bound is unchanged.)
Timeline: Step index, traffic weights, pause conditions, abort/promote-full, and stable-ReplicaSet moves are all recorded as distinct events; a Rollout sits in Progressing for the whole canary, so phase alone would show nothing.