Argo Rollouts and Workflows

Argo Rollouts and Argo Workflows

When a cluster has Argo Rollouts or Argo Workflows, Sextant shows their objects in two sidebar sections, with their status read the way the projects' own tools read it: a Rollout's step, weights, ReplicaSets and analysis, and a Workflow's tree of steps with the failed one and its logs. Rollouts can be promoted, fully promoted, aborted, retried, paused and resumed, and Workflows suspended, resumed, stopped and terminated, with the same changes the kubectl argo rollouts plugin and the argo CLI send; neither tool is needed.

Both projects use the API group argoproj.io, like Argo CD; each has its own section, and the Argo CD section is unchanged.

Contents: The sections · Rollouts · Rollout actions · Workflow actions · Analysis runs · Workflows · Step logs · Cron workflows · Problems · Limits · What Sextant does not do

The sections

Section	Kinds
Argo Rollouts	Rollouts, Analysis Runs, Analysis Templates, Cluster Analysis Templates, Experiments
Argo Workflows	Workflows, Cron Workflows, Workflow Templates, Cluster Workflow Templates

A section appears only when the cluster serves at least one of its kinds, and lists only the kinds it serves, at the version it serves; a project installed after you connected shows up without reconnecting. The section header shows how many rollouts need attention or how many workflows failed recently (see Problems).

Rollouts

The Rollouts table has the columns Status, Strategy (canary or blue-green), Step (for example 2/5), Weight (of a canary) and Ready.

The status is the one kubectl argo rollouts get rollout shows: Healthy, Progressing, Paused or Degraded, with the controller's message. A Rollout also counts as Progressing while the controller has not seen its latest spec (or the latest spec of the workload it references) yet, or while it is being resumed; the details say which. For a controller older than v1.0, which writes no phase, Sextant works the status out as the plugin does.

A Rollout's details show:

• Rollout: status and message, strategy, step, the Set weight (what the steps ask for: 0 after an abort, 100 once every step is done) and the Actual weight (from the traffic router when there is one, else the canary ReplicaSet's share of the available pods), what paused it (Paused by), the stable and canary (or active and preview) Services, and the stable and current pod templates.
• Steps: the canary steps, with the current one marked; All steps are complete. once they are. After an abort, a note says the stable ReplicaSet serves all traffic until the rollout is retried.
• ReplicaSets: the ReplicaSets the Rollout owns, each marked stable, canary, active, preview or old, with its revision and available pods.
• Analysis runs: the newest 20 analysis runs of the Rollout with their phase, start and message.

Rollout actions

A Rollout offers the actions that apply to it now:

Action	Offered when	What it does	Same as
Promote	the rollout is paused, or a canary is between its steps	leaves the pause and goes on to the next step	kubectl argo rollouts promote
Promote fully	an update is not fully promoted yet, or the rollout is paused	skips the remaining steps, pauses and analysis and makes the new ReplicaSet stable	kubectl argo rollouts promote --full
Abort	an update is under way	stops the update and sends all traffic back to the stable ReplicaSet; the rollout stays Degraded until it is retried or updated	kubectl argo rollouts abort
Retry	the update was aborted	starts the aborted update again from the first step	kubectl argo rollouts retry
Pause	the Rollout is not paused by hand (spec.paused is not set)	pauses the Rollout; it makes no progress until it is resumed or promoted	kubectl argo rollouts pause
Resume	the Rollout is paused, by hand or by the controller	leaves the pause (see below)	the plugin's former resume command, and Argo CD's Rollout resume action

Each action opens a confirmation that reads the Rollout again and lists exactly what will be sent: the change to the Rollout's status (where the controller reads promote, abort and retry), the change to the Rollout itself (spec.paused: false, when it is paused; spec.paused: true for Pause), and the change sent instead to a cluster whose Argo Rollouts (v0.9) has no status subresource. These are the plugin's own JSON merge patches; Sextant chooses between them the same way the plugin does. Promote fully on a rollout that is already fully promoted and not paused says there is nothing to change and cannot be confirmed.

When you confirm, Sextant reads the Rollout once more. If the controller moved it meanwhile and the changes would be different, nothing is sent: the dialog shows the new changes for you to confirm again. Each change is sent once and never repeated.

Pause sends the JSON merge patch {"spec":{"paused":true}} to the Rollout, exactly as kubectl argo rollouts pause does.

Resume. The plugin no longer has a resume command (it was replaced by promote); its last version sent {"spec":{"paused":false},"status":{"pauseConditions":null}}, and Argo CD's Resume action sets the same two fields. Sextant sends that change in two parts, each only where it applies: {"spec":{"paused":false}} to the Rollout when spec.paused is set, and {"status":{"pauseConditions":null}} to the status subresource when pause conditions exist (for Argo Rollouts v0.9, which has no status subresource, the whole old patch goes to the Rollout). Resume on a canary pause step advances the rollout like Promote: with the pause conditions cleared, the controller counts that step as completed and goes on to the next one. Unlike Promote, Resume never writes currentStepIndex and never lifts the controller's own pause; the dialog says this in plain words.

Only the Rollout kind can have its status changed this way, and only from the window: AI agents and extensions have no tool or method for it.

Workflow actions

A Workflow offers Suspend, Resume, Stop and Terminate when they apply, each after a confirmation. The Workflow kind has no status subresource, so every action is one JSON merge patch of the Workflow object, sent once and never repeated. They follow the Argo Workflows code that argo suspend, argo resume, argo stop and argo terminate call.

Action	Offered when	What is sent	Refused / nothing to do
Suspend	the Workflow is not finished and not suspended	spec.suspend: true, with the Workflow's resourceVersion and the Argo actor labels removed. No new steps start; running ones go on.	refused for a finished Workflow; nothing when it is already suspended
Resume	the Workflow is suspended, or a suspend step is waiting	spec.suspend removed when it is set; every waiting suspend step marked Succeeded with its finish time, its message kept; an output parameter that takes a supplied value gets its valueFrom.default as its value, also exported to the Workflow's global outputs. Sent with the resourceVersion, actor labels removed.	refused when the node status is compressed or offloaded (Sextant cannot read it without the controller); nothing when neither applies
Stop	the Workflow is not finished and not already being stopped	{"spec":{"shutdown":"Stop"}}. Running steps stop; exit handlers still run.	refused for a finished Workflow; nothing when already stopping
Terminate	the Workflow is not finished and not already being terminated	{"spec":{"shutdown":"Terminate"}}. Running steps stop and nothing else runs, exit handlers included.	refused for a finished Workflow; nothing when already terminating

Suspend and resume are an update in the Argo code, so their patch carries the resourceVersion of the Workflow as read right before sending. If the Workflow changed in between, the API server answers with a conflict; the dialog shows it and Sextant does not retry (Argo's own code does; Sextant never repeats a change). The dialog lists the patch with the resourceVersion and finish time as of opening and says both are taken again when you confirm: the plan is rebuilt from a fresh read, and if it differs from what you saw, the new plan is shown instead of being sent.

Sextant has no Argo user identity, so it only removes the workflows.argoproj.io/actor, actor-email, actor-preferred-username and action labels (the ones present), as Argo does without a user, and the resume message names nobody. The variants that act on chosen nodes (argo resume or argo stop with --node-field-selector, argo node set) are not offered.

Retry is not offered. argo retry rebuilds the Workflow's node tree (it resets and deletes nodes, scrubs references, drops the exit-handler subtree, rewrites labels and phase, and deletes the pods of reset nodes) in several requests that are not atomic, with a reset plan that changes between Argo releases. Done from the window it could leave a Workflow half reset. A failed Workflow's details tell you to run argo retry <name> -n <namespace> instead.

AI agents and extensions get none of these actions.

Analysis runs

An Analysis Run's details list its metrics with their provider and the counts of Successful, Failed, Inconclusive and Error measurements, and the value and message of the newest measurement that failed, errored or was inconclusive. The table shows the phase, the Rollout it belongs to and its message. Analysis templates show their metrics.

Workflows

The Workflows table has Phase, Progress (for example 3/5), Duration and Failed step: the name of the step that failed and its message.

A Workflow's details show the phase, progress, start, finish and duration, its message, the failed step and its message, and the cron workflow or workflow template it came from, as links. Below is Steps, the tree of the Workflow's nodes, read as the Argo UI reads it:

• it starts at the root, collapsed below it; expand a node to see its children;
• Show the failed step opens the path to the step that failed first; Collapse all closes the tree again;
• a DAG task with two parents is shown once;
• each node shows its type, phase, duration and message, and a step that ran in a pod links to the pod.

The failed step is the first pod or container step to fail or end in an error; when there is none, the first failed node other than the root.

Step logs

A step that ran in a pod has Logs: it opens that pod's logs in the dock, as Logs on a pod does. Sextant finds the pod by the name the controller gives it, for both pod name formats (workflows.argoproj.io/pod-name-format v1 and the default v2), including the containers of a container set, which run in one pod. If the pod is gone (Argo's pod garbage collection deletes finished pods), the error says so.

Cron workflows

The Cron Workflows table has Schedule, Suspended, Active and Last scheduled. Their details add the schedules, time zone, concurrency policy, the active workflows (as links) and the counts of succeeded and failed runs. Workflow templates show their entrypoint and templates.

Problems

Two problem categories feed the Problems page, the notifications and the sections' counters. Both are on by default and can be turned off under Notify about like any other.

Category	Problems
Argo Rollouts	A Rollout that is Degraded (after a minute) or aborted, or whose step, background, pre-promotion or post-promotion analysis run the Rollout reports as Failed or Error. One notification per Rollout.
Argo Workflows	A Workflow that failed or ended in an error in the last 24 hours. The runs of one cron workflow notify as one.

To keep the background cost low whatever the size of your Workflows, Sextant watches only the failed ones, by the phase label the controller puts on them (workflows.argoproj.io/phase in (Failed,Error)), and only their names and labels. So a Workflow problem has no message; open the Workflow for the failed step and its message. A failure counts from when Sextant saw the Workflow fail, or, for one that had already failed when Sextant connected, from its creation; a long-running Workflow that failed shortly before you connected may therefore not be listed. Analysis runs themselves are never watched in the background: only what the Rollout reports about them counts.

AI agents do not get these categories from get_problems.

Limits

• Workflow tree: at most 500 rows are drawn ("Only the first 500 of N steps are shown."). Workflows whose node status the controller offloaded to its database or stored compressed show no tree; the details say so.
• Analysis runs of a Rollout: the newest 20.
• Workflow problems: at most 5000 failed Workflows are watched (beyond that the Problems page says the list is incomplete), and at most 500 problems are listed, the most recent failures first.

What Sextant does not do

• It does not run the kubectl argo rollouts plugin or the argo CLI, and does not talk to the Argo Workflows server; everything goes through the Kubernetes API.
• It does not resubmit or retry Workflows, or act on single nodes of a Workflow; for that use the Argo UI or CLI. Like any object, Workflows and Rollouts can still be edited or deleted under the usual confirmations.
• It writes nothing to the cluster beyond the change you confirmed, marked with the field manager sextant.

Next: Ecosystem views, Problems and notifications, Using Sextant.