feat: Argo CD read side - Application columns, :argocd view, fleet count, ownership tree

[nklmilojevic]

Agreed scope from #412 with @mesutoezdil. Argo CD gets the same read side Flux already has: curated Application columns, an :argocd view, a count in :fleet, and an ownership tree behind a keypress. Everything comes from the Application CRD, no Argo API or token.

Three PRs, in this order, each mergeable on its own with tests and docs. The closed drafts #518, #519, #520 already follow this split, so rebasing them onto this issue is the expected path.

Ground rules

• CRD only. Read argoproj.io/v1alpha1 Applications. Never the Argo CD API, a token, or Argo's cluster Secrets.
• Same shape as Flux. Pure module src/argocd.rs (unit tested without a cluster) plus a driver src/app/argocd.rs, mirroring gitops.rs / app/gitops.rs. The view reuses explain::Finding, Level, Target and ui::draw_findings. No new rendering code.
• Reads only. Sync and suspend stay on t.
• Tests through handle_key for every user-visible behaviour. Cluster::fake() already registers argoproj.io/applications.

PR 1: Application columns and :argocd view

Columns

columns_for("argoproj.io", "applications") returns a curated set, six columns like Flux:

Column	Source
NAME
SYNC	status.sync.status
HEALTH	status.health.status
REVISION	status.sync.revision, falling back to status.operationState.syncResult.revision
AUTO-SYNC	three states, see below
AGE

• REVISION shortens a full 40-char SHA to 7. Chart versions and branch names stay as they are.
• AUTO-SYNC is three states, not a boolean:
  • on: spec.syncPolicy.automated is present
  • manual: no automated block and no stash annotation. Normal config, not a fault.
  • suspended: no automated block and sofka.io/argocd-automated is set (what t → Suspend writes, see app/helpers.rs)
• SYNC / HEALTH sort as text, the way FLUX_OBJECT_COLUMNS READY does.
• ApplicationSets keep default columns.

:argocd view

Palette names argocd and argo. Keymap mode argocd with the same bindings as gitops: enter accept, esc back, q close, j/k, g/G, r refresh.

Opens from two places:

1. An Application. Re-read it like spawn_gitops does, then render.
2. Anything Argo manages. Resolve the owning Application from tracking metadata and render it, with the headline stating the relationship (Deployment/web is managed by Application/guestbook).

Owner resolution:

• argocd.argoproj.io/tracking-id annotation first (<app>:<group>/<kind>:<ns>/<name>). Only Argo writes it. If it names an Application that doesn't exist, that's a warning (dangling reference).
• Instance label second (app.kubernetes.io/instance, then argocd.argoproj.io/instance). Helm stamps the same label on everything it installs, so a label with no matching Application renders as "not managed by Argo CD", not as an error.
• Argo writes <namespace>_<name> for Applications outside its own namespace, bare <name> otherwise. _ is illegal in both, so the split is exact.
• Look up by metadata.name field selector across namespaces, not a full list. Clusters hold thousands of multi-KiB Applications. If several match, pick the one whose status.resources[] lists the object.

Findings, top to bottom:

• Headline: Application/<name>: <sync> / <health>. Level from the pair: Synced+Healthy Good, Progressing Info, OutOfSync Warn, Degraded/Missing/Unknown Critical.
• Application: project, destination (see below) and namespace, auto-sync state, deployed revision.
• Source: repo URL, path or chart, targetRevision. Multi-source Applications show the first source.
• Managed resources: one line per status.resources[] entry with its own sync and health. Capped at 50 with a remainder line. Each line carries a Target resolved through the kind registry by kind and group, a Knative Service must not open the core one. Application entries (app-of-apps) jump to that Application, where :argocd opens its view again.
• Blocking: what stops this Application from being Synced and Healthy, most serious first, or one line saying nothing does:
  1. suspended by sofka (stash annotation present)
  2. status.operationState.phase Failed / Error with its message
  3. conditions by priority: ComparisonError, InvalidSpecError, SyncError, UnknownError, then SharedResourceWarning, OrphanedResourceWarning, RepeatedResourceWarning
  4. Degraded / Missing resources by name
  5. OutOfSync resources by name
  6. Degraded with nothing above naming a cause: say so. Argo rolls health up from live state it doesn't publish per resource.

Destination

spec.destination.server (or .name) is resolved against the kubeconfig:

• https://kubernetes.default.svc (with or without :443), or a URL equal to the connected Cluster.cluster_url, is the current cluster.
• Otherwise match against every kubeconfig cluster's server and show the context name. Needs a small helper next to k8s::context_info, which today resolves one context at a time.
• Unresolved: show the raw server URL.

Only a current destination yields jump targets. On a remote destination enter flashes where the object lives instead of opening a same-named object here. This reads the user's kubeconfig, never Argo's cluster Secrets.

Shared with :gitops

Request-generation guard so only the latest report updates findings. Closing the view, refreshing, changing source or context cancels pending results. A missing Application is a warning, a failed read stays an error. Never render a denied read as "not found".

Tests

• src/argocd.rs: accessors, three auto-sync states, blocking precedence, annotation vs label, dangling vs unmanaged, group-aware targets, remote destination yields no targets, SHA shortening, the cap.
• src/app/tests.rs through handle_key: open on an Application, open on a managed Deployment, enter jumps to a managed resource, enter on a remote line doesn't navigate, r re-gathers, esc cancels.
• columns.rs cell tests.

Docs

docs/keys.md row, docs/features.md (GitOps and Helm section plus the palette command list), ? help in src/ui.rs, docs/keybindings.md (new argocd mode table).

PR 2: Argo CD count in :fleet

• New FleetRow.argocd_degraded: Option<usize>. None when the cluster has no argoproj.io Application kind, rendered argo — like flux —.
• Counts Applications that are OutOfSync, or whose health is Degraded, Missing or Unknown. Progressing is transient and not counted. Empty status is a freshly created Application, not a fault.
• Pages with limit / continue (500 per page) and keeps only the count. list_or_warn materialises the whole list, which at thousands of multi-KiB Applications across concurrent contexts is tens of MiB. Leave the Flux path alone in this PR.
• A failed or timed-out list is None plus a warn entry so the row goes to FleetStatus::Error, not a confident zero.
• is_healthy() treats a non-zero count as unhealthy. draw_fleet gets an argo cell next to flux.
• Tests: fleet row healthy / unhealthy with and without the CRD, paging count over a fake page sequence.
• Docs: docs/providers.md#fleet-dashboard, docs/features.md.

PR 3: c expands what a managed resource owns

• In :argocd, c (discover_children) on a managed-resource line with a current-cluster target walks ownerReferences down: Deployment → ReplicaSet → Pod, CronJob → Job → Pod, StatefulSet / DaemonSet / Job → Pod. c again collapses.
• Reuse adjacent. Child kinds come from adjacent::children_for (BUILTIN_CHILDREN plus [views."…"].children), matching with adjacent::owned_by. No second hard-coded child list. Depth capped at 2. Cost is one GET for the parent UID plus one LIST per child kind in the namespace, reused at every depth.
• Drop ReplicaSets scaled to zero that own no pods. With the default revisionHistoryLimit the live one is otherwise buried under ten dead ones.
• Child rows are indented findings with their own Target and a one-word state: pod phase or waiting reason (CrashLoopBackOff), ReplicaSet ready/desired, Job Complete / Failed. Level follows the state.
• Behind a keypress, not on open. A failed LIST is a warning line, not an empty tree. r collapses everything. Expansion results are request-guarded like the main report.
• Tests through handle_key: expand shows the pod under the ReplicaSet, a dead ReplicaSet is hidden, c twice collapses, c on a remote or heading line flashes and does nothing.
• Docs: docs/keys.md, docs/features.md, docs/keybindings.md (c in argocd mode), ? help in src/ui.rs.

Out of scope

ApplicationSet columns or views, diff, sync options, rollback, Argo CD API access, reading Argo cluster Secrets, a new config section. Separate discussions if wanted.

Open questions

1. Fleet count: include Progressing or not. Spec says no.
2. PROJECT column in the table or view only. Spec says view only, keeps the table at six columns like Flux.

Discussion: #412

[mesutoezdil]

yeah, both of those work for me.

progressing, leave it out for sure. it isn't really a failure, just means something's mid-rollout. i had a few sitting like that while i was testing and by the time i looked again they'd sorted themselves out on their own. counting them would just give you a number that bounces around. degraded and missing are what you actually want to catch from the fleet view.

project in the view only, yeah, agreed. six columns already start getting chopped around 90 cols on my terminal. and project isn't really something you scan a list for, it's more a thing you glance at once when you're already inside a specific app. rather keep the room for revision and auto-sync.

[nklmilojevic]

@mesutoezdil sounds good for me - please continue work when/as you see fit.

[mesutoezdil]

There might be a few minor bugs that I missed, but as people use it, more issues will come to light.

few things i noticed while testing that could go in later, roughly in the order
i'd want them:

nr1// multi-source apps. the view only shows the first source right now, which is
what we agreed, but on my clusters that's 142 of 159 apps on one and 2540 of
4032 on another. a typical one is a helm chart plus a separate git repo
holding the values, so right now you can't see where the values came from.
cheap fix, just list them all instead of the first.

nr2// degraded with nothing explaining it. 84 apps on one of my clusters are
degraded while status.resources[] says nothing is wrong, so you land on
"degraded, but no managed resource reports it" and then have to go hunting
with c. could auto-expand the workloads in that case.

nr3// applicationsets. 134 of them on one cluster and we show nothing about them.
:argocd on one walks up to the app that created it, which is handy, but you
still can't see the generator or how many apps it produced.

nr4// drilling into the fleet count. argo 14✗ tells you there are 14 but not which
ones, you have to switch context and sort.

nr5// staleness. status.health.lastTransitionTime is right there, so "degraded
since 4m" would separate something that just broke from something that's been
sitting broken for a week.

[mesutoezdil]

There might be a few minor bugs that I missed, but as people use it, more issues will come to light.

few things i noticed while testing that could go in later, roughly in the order i'd want them:

nr1// multi-source apps. the view only shows the first source right now, which is what we agreed, but on my clusters that's 142 of 159 apps on one and 2540 of 4032 on another. a typical one is a helm chart plus a separate git repo holding the values, so right now you can't see where the values came from. cheap fix, just list them all instead of the first.

nr2// degraded with nothing explaining it. 84 apps on one of my clusters are degraded while status.resources[] says nothing is wrong, so you land on "degraded, but no managed resource reports it" and then have to go hunting with c. could auto-expand the workloads in that case.

nr3// applicationsets. 134 of them on one cluster and we show nothing about them. :argocd on one walks up to the app that created it, which is handy, but you still can't see the generator or how many apps it produced.

nr4// drilling into the fleet count. argo 14✗ tells you there are 14 but not which ones, you have to switch context and sort.

nr5// staleness. status.health.lastTransitionTime is right there, so "degraded since 4m" would separate something that just broke from something that's been sitting broken for a week.

nr6// t from inside the view. minor, and it's a read-only view on purpose, but you currently have to back out to the table to sync something you're looking at.

@nklmilojevic Should we discuss the points above specifically under "Discussions," or should we continue under this issue?

[nklmilojevic]

We can continue under this issue. Feel free to do follow-ups now that we agreed on what it should be.

[mesutoezdil]

all done, PRs up

I think we've done everything we could for Argocd :)

nr6 (t from inside the view) is next, but that one still needs a decision since it goes against the read-only rule
will hold off until we talk it through here

[mesutoezdil]

Here's what got added for ArgoCD:

• Application table got SYNC/HEALTH/REVISION/AUTO-SYNC columns plus a :argocd view
• Fleet dashboard now shows a count of degraded Applications per context
• c lets you drill down from a Deployment/CronJob to the actual broken Pod
• Multi-source apps now show all their sources, not just the first one
• When "degraded" doesn't say why, sofka now digs in and finds the real cause itself
• Job status (Complete/Failed) reads properly now, used to show nothing
• ApplicationSets got their own columns and view: see how many apps it made, what generator it uses
• Hitting ⏎ on a degraded fleet count drops you straight into those apps, no more hunting
• Shows how long an app's been in its current state (degraded/healthy) too

[ShmuelOps]

Following up on #573, closed pending discussion here — sorry for jumping ahead. The closed PR works as a preview; I'd rebase and reopen it if agreed, split however you prefer.

A. Navigate from :argocd into the cluster and back (#573)

Context: hub cluster running Argo CD, most Applications deploy to spoke clusters. Since #570 a remote destination resolves to a kubeconfig context, but ⏎ on a managed resource of one still flashes "these resources live in prod; switch with :ctx prod". Getting to the pod behind a Degraded row is then :ctx, pick the kind, pick the namespace, filter by name — and the same in reverse to come back.

Proposal, reads only, no new keys or config:

1. ⏎ on a remote managed resource jumps to it. Switch to the resolved context and, once the connection lands, open the object as a root view scoped to metadata.name. The kind is resolved against the destination cluster at landing time (the hub may not know the CRD). Reuses the deferred-navigation pattern of :pods @ctx ns — own pending_* slot, same one-at-a-time rules, cleared on a failed switch. Heading rows and unresolved destinations keep today's flash. This revises the PR-1 line "on a remote destination enter flashes where the object lives instead of opening a same-named object here": that rule guarded against opening the wrong cluster's object, which was the only option when destinations couldn't be resolved. Now they can, so the guard can become the jump.
2. esc comes back. The jump records the hub context and the object the view was opened for; esc at the jumped view's root switches back and reopens :argocd on it, with the table underneath set to that kind. Moving to another root view in the remote cluster drops the way back, so esc there stays an ordinary root esc.
3. ⏎ on an Application / ApplicationSet row opens :argocd instead of YAML; y keeps the YAML. Group-guarded like the CAPI machinedeployments arm.
4. ⏎ on the "Managed resources" heading opens all of them as a workspace in the destination cluster: one live table per kind, Tab cycling, esc back to the view. Each table is filtered name=a || name=b to the objects Argo listed — by name rather than the instance label, because with annotation tracking Argo sets no label at all, and a Helm-rendered app.kubernetes.io/instance carries the release name, not the Application's. Goes through the existing open_workspace path with an optional return.
5. → on rows that now jump (draw_findings takes the predicate from the view; Explain/GitOps unchanged), and header hints enter argocd / t suspend/sync on Applications.

Open questions: (a) OK to revise the remote-enter rule this way? (b) One PR, or split 1–3 (jump + back + enter) from 4–5 (workspace + markers)? (c) Workspace tables by listed names, or would you rather it read application.instanceLabelKey from argocd-cm and filter by label?

[mesutoezdil]

Following up on #573, closed pending discussion here — sorry for jumping ahead. The closed PR works as a preview; I'd rebase and reopen it if agreed, split however you prefer.

A. Navigate from :argocd into the cluster and back (#573)

Context: hub cluster running Argo CD, most Applications deploy to spoke clusters. Since #570 a remote destination resolves to a kubeconfig context, but ⏎ on a managed resource of one still flashes "these resources live in prod; switch with :ctx prod". Getting to the pod behind a Degraded row is then :ctx, pick the kind, pick the namespace, filter by name — and the same in reverse to come back.

Proposal, reads only, no new keys or config:

1. ⏎ on a remote managed resource jumps to it. Switch to the resolved context and, once the connection lands, open the object as a root view scoped to metadata.name. The kind is resolved against the destination cluster at landing time (the hub may not know the CRD). Reuses the deferred-navigation pattern of :pods @ctx ns — own pending_* slot, same one-at-a-time rules, cleared on a failed switch. Heading rows and unresolved destinations keep today's flash. This revises the PR-1 line "on a remote destination enter flashes where the object lives instead of opening a same-named object here": that rule guarded against opening the wrong cluster's object, which was the only option when destinations couldn't be resolved. Now they can, so the guard can become the jump.
2. esc comes back. The jump records the hub context and the object the view was opened for; esc at the jumped view's root switches back and reopens :argocd on it, with the table underneath set to that kind. Moving to another root view in the remote cluster drops the way back, so esc there stays an ordinary root esc.
3. ⏎ on an Application / ApplicationSet row opens :argocd instead of YAML; y keeps the YAML. Group-guarded like the CAPI machinedeployments arm.
4. ⏎ on the "Managed resources" heading opens all of them as a workspace in the destination cluster: one live table per kind, Tab cycling, esc back to the view. Each table is filtered name=a || name=b to the objects Argo listed — by name rather than the instance label, because with annotation tracking Argo sets no label at all, and a Helm-rendered app.kubernetes.io/instance carries the release name, not the Application's. Goes through the existing open_workspace path with an optional return.
5. → on rows that now jump (draw_findings takes the predicate from the view; Explain/GitOps unchanged), and header hints enter argocd / t suspend/sync on Applications.

Open questions: (a) OK to revise the remote-enter rule this way? (b) One PR, or split 1–3 (jump + back + enter) from 4–5 (workspace + markers)? (c) Workspace tables by listed names, or would you rather it read application.instanceLabelKey from argocd-cm and filter by label?

thx

nr1 // #570 makes sense, that is a bug.. but the "no jump on remote" thing wasn't an accident, it was the safety property i deliberately picked for #532.. didn't want a plural resolving against the wrong cluster and silently opening sth with the same name

nr2// #570 makes that resolution a lot more reliable, so the reasoning for revisiting it isn't crazy, i get where it's coming from

nr3// still want to think it through properly bfr flipping a rule we called "core" on purpose, not just take it bcs sb opened a PR for it also it's 6 commits bundled.. jump, esc-back, enter-opens-argocd, header hints, → markers, and a whole workspace thing for managed resources. even if we're fine with 1-3, i wouldn't want 6 (the workspace part) riding along without its own look

nr4// @nklmilojevic wdyt? open to revisiting the remote-jump rule now that #570's in, or keep it as is for now?

[nklmilojevic]

Just getting back to this. I'm not that much familiar with ArgoCD as I have been using Flux my whole life. @mesutoezdil I'd trust your opinion on this moving forward so feel free to suggest!

[mesutoezdil]

Just getting back to this. I'm not that much familiar with ArgoCD as I have been using Flux my whole life. @mesutoezdil I'd trust your opinion on this moving forward so feel free to suggest!

thx

@ShmuelOps you can open prs if you want according to the outcome of the discussions
just nr1 and nr2 for now..