ArgoCD

[mesutoezdil]

Do you wanna integrate ArgoCD too? I see now just Flux.

If you're interested, I can work on this.

[nklmilojevic]

Hi,

Converted this to a discussion (please see the pinned issue).

There is already ArgoCD integration, is there something you are missing?

sofka/README.md

Line 39 in 98e24e1

- **Argo CD built in** - `t` suspends, resumes, and syncs ArgoCD Applications.

[mesutoezdil]

Thanks for the reply.
I meant a proper ArgoCD integration like the Flux one.. showing Application health/status/sync-tree in the UI itself, not just the t action for suspend/resume/sync.
That part is already there, but there's no visual view of ArgoCD state comparable to what Flux gets.

(I like this one too: https://github.com/vvrnv/argo9s)

[nklmilojevic]

Aha, I get it! I would welcome a contribution here. An Application detail view with health, sync status, revision, and managed resources would be a useful first step.

Could you outline the proposed view and navigation here? For the resource tree, please also describe which data would come from Kubernetes and whether it would need access to the Argo CD API. We can then agree on the scope before implementation.

[mesutoezdil]

Aha, I get it! I would welcome a contribution here. An Application detail view with health, sync status, revision, and managed resources would be a useful first step.

Could you outline the proposed view and navigation here? For the resource tree, please also describe which data would come from Kubernetes and whether it would need access to the Argo CD API. We can then agree on the scope before implementation.

thx
I don't have time during the week, but I'll take a walk through the architecture on the weekend

[mesutoezdil]

I gave this a try and opened three draft PRs.

#518 adds SYNC/HEALTH columns for Applications and an :argocd view. It shows sync and
health, the source, what the app manages, and what is blocking it. Everything comes from the CRD, so no Argo CD API or token is
needed.

#519 adds an Argo health count per cluster to :fleet.

#520 lets you open a managed resource and see what it owns.

They build on each other in that order. Still drafts, so tell me if the scope should change.

[nklmilojevic]

Hey @mesutoezdil I closed the PR until we agree about the scope fully and create an issue for it so agents/you can do a proper integration. Can you outline how full integration would work? Afterwards I will open up an issue and then we can continue working on it. I know it is a bit of a process, but it ensures that we do not get bloated with bogus PRs and non-agreed scope. Thank you!

[mesutoezdil]

ok, fair enough. bit of a gut punch to see all three closed at once though, i'd been chipping away at this for days and ran every bit of it against my own clusters rather than just writing tests. drafts felt like the right place to argue about scope. anyway.

so, the whole thing as i see it.

you don't need the argo api for any of this. the application crd already carries sync.status, health.status, sync.revision, the source, the destination, the conditions, and status.resources[]. that's enough for everything below.

the one thing it can't give you is the tree the web ui draws. status.resources[] is flat, it's just what the application applied, not what those things went on to create. argo builds the tree in its api layer. but you can get the same thing out of kubernetes, because the links are sitting right there on the children as ownerreferences.

columns are the easy bit. applications currently lands on the default columns so all you see is name and age. sync, health, revision, auto-sync.

auto-sync tripped me up. i started with a boolean and it was wrong. an application with no automated block hasn't been suspended, it's just synced by hand, which is a completely normal way to run things. on one of my clusters 24 out of 53 apps are like that. a boolean would've painted half of them as suspended. so it needs to be three states, and the suspended one is only when our own stash annotation is there.

then the view itself, :argocd. it's the same shape as :gitops and reuses the finding model, so nothing new on the rendering side. project, destination, source, the revision that's actually deployed, then every managed resource with its own sync and health, then a bit at the bottom saying what's actually stopping it. suspended policy, comparisonerror, a failed operation, something degraded, whatever. enter jumps to a resource.

should work in reverse too. stand on a deployment and it walks back to the application that owns it. worth knowing the tracking annotation is reliable and the app.kubernetes.io/instance label isn't, since helm stamps the same label on everything it installs. i ran into this on coredns, it looked like argo had a dangling reference when really it was just a helm release wearing the same label.

the bit i'm least sure about is remote destinations. on my setup most applications live in one cluster and deploy into another, so the objects they manage aren't in the cluster you're staring at. jumping to one would quietly open some unrelated object that happens to share the name. what i ended up doing was matching spec.destination.server against the kubeconfig so you see the context name instead of a rancher url, and then just not offering a jump if it's somewhere else. it reads the kubeconfig you already have rather than argo's cluster secrets. curious what you think.

:fleet already tracks flux failures per context so argo fits the same slot. count of outofsync or unhealthy apps, dash when the crd isn't installed. it does need to page rather than list everything, one of my clusters sits at around 4000 applications and they're not small.

last piece, pressing c on a managed resource to see what it owns. deployment, replicaset, pod. behind a keypress because it's a read plus a list per kind, not something you want firing on every open. one detail that turned out to matter a lot more than i expected: you have to drop the scaled-to-zero replicasets that own nothing, otherwise revisionhistorylimit means you're looking at ten dead ones and the live one is lost in there.

that expansion is also what found a real bug for me, incidentally. an application was sitting at degraded with absolutely nothing in status.resources[] to explain why, and opening the tree turned up a pod stuck in crashloopbackoff.

i'd leave applicationset views, diff, sync options and rollback alone for now. all of that wants api credentials.

throw out whatever you don't want and i'll work to the issue.

[nklmilojevic]

Yeah, you got in a cross-fire because there were quite a lot of low effort PRs without any understanding, which yours aren't for sure, I just have to keep the same standard and processes on the repo.

Issue is up: #532. It's basically your outline with a few decisions locked in:

• three PRs in your order, so rebasing feat: Argo CD Application view and columns #518/feat: count degraded Argo CD Applications in the fleet dashboard #519/feat: expand what an Argo CD managed resource owns #520 onto the issue is the path, not a rewrite
• fleet count is OutOfSync + Degraded/Missing/Unknown, Progressing left out because it flaps. Push back if you disagree
• for the c tree, reuse adjacent::children_for and owned_by instead of a separate child kind list. It already knows Deployment → ReplicaSet → Pod and honours [views].children
• remote destinations: your kubeconfig matching is the right call, keep it. No jump when it's elsewhere

Two open questions at the bottom of the issue, answer there.

Reopen #518 first when you're ready and link the issue. Thanks for sticking with it :)