Remove the Graph tab from the Applications view

[lasomethingsomething]

Relates to https://github.com/weaveworks/weave-gitops-interlock/issues/525. Decision prompted by its history of issues, with the new Interlock issue being the latest manifestation. Also spoke to CX, product team, members of the eng team, and got support for removal.

We will work on producing a new-and-improved graph with a vertical orientation, but not right now.

Per @darrylweaver, this issue has always been true of the graph view, affecting every version: "I avoid showing much on this page because of it."

Previous, related issue (h/t @yiannistri for digging up) weaveworks/weave-gitops#3302 and relevant PR weaveworks/weave-gitops#3320

Also found this old issue: weaveworks/weave-gitops#1956

[lasomethingsomething]

cc @joshri @jpellizzari -- we're seeing this issue again, will discuss at refinement today.

[jpellizzari]

This is being caused by inconsistent responses from the backend. We do separate requests from all the namespaces, and if one of them fails, it's data comes back as empty, and nodes get removed.

My advice for fixing this would be to pursue one of these options:

• Turn off polling for that page (easy, but makes it inconsistent with the rest of the UI)
• Move to the explorer backend (harder, but will produce a performant and predictable graph)

We should also add some type of animation when the graph reflows so that it is less jarring and the user's eye can follow the change.

[lasomethingsomething]

Chatted about this at Wild Wa refinement. The team raised several questions:

• why is rate limiting set to five seconds?
• could we overcome the current issue by giving the user control of updates, via a button?
• How useful would this be for a Flux or Weave GitOps user?
• Isn't this like Argo, but reversed? (MB: "In ArgoCD the analogous view is quite neat because you can see your new pods start up and reach a ready state. Not sure if it's more than "neat" though.")
• Should we just delete this?

I shared the comments with @darrylweaver and @steve-fraser. Their response:

• a visualization that facilitates better traceability of where an object comes from would be useful.
• Users have this problem: "I see my object in the cluster. Now where is this actually in Git, and how was it deployed to the cluster?”
• Users do not want to end up at a dead end when trying to trace the source of a HelmRelease and links to source objects.
• Being able to trace how an object is deployed by clicking a link to the previous object, from the Application view, would be useful.
• Protocol Labs wanted this a long time ago, but they are no longer a customer.
• If providing the link to Git is too heavy a task, then just adding a link to it in the existing details page so that a user can get back from a HelmRelease object would be a low-effort, high-impact alternative. "Then I would at least be able to get back to which GitRepository source it came from." (For example, take me here instead of the general repo.)

Regarding whether to remove the Tab or not: It's the closest thing to a traceability capability that we currently offer. We'd likely need to implement something like it in the future. If reusing the Graph view represents a sunken cost, then we should make the main Application details view better instead. See #2102, a past proposal to do that (note that it does not address traceability). See also this Interlock issue, which proposes a sunburst visual as an alternative graph format.

From Yiannis: "my suggestion would show a link to a GitRepository, HelmRepository, OCIRepository or Bucket details page in the UI."

[jpellizzari]

why is rate limiting set to five seconds?

Assuming this means "polling interval", the reason that an arbitrary value was chosen.

could we overcome the current issue by giving the user control of updates, via a button?

Sure, but they would have the same issue of a node disappearing on button click.

How useful would this be for a Flux or Weave GitOps user?

This was always intended as a "demo sugar" feature that looked interesting and presented the data in a hierarchical way. The K8s data model doesn't allow for querying hierarchically, so we are always fighting the backend. Source: I originally came up with this visualization just to see if I could get it to work. There wasn't much though given to its future (although it is somewhat future-proofed and can express any parent-child relationship that we want to show).

Isn't this like Argo, but reversed? (MB: "In ArgoCD the analogous view is quite neat because you can see your new pods start up and reach a ready state. Not sure if it's more than "neat" though.")

What if a Kustomization outputs something that isn't a Pod? How do we know if a PersistentVolumeClaim (for example), is Ready?

I shared the comments with @darrylweaver and @steve-fraser. Their response:

These all seem like navigation problems that can be solved with some clever links in various places.

Regarding whether to remove the Tab or not:

The Graph view itself is fairly simple to implement. The server code to make the graph possible is where the "magic" happens, with a little bit of recursion on the FE. I don't feel strongly about the Graph itself, but the request/server logic might be worth keeping around.

[squaremo]

I shared the comments with @darrylweaver and @steve-fraser. Their response:
[...]
These all seem like navigation problems that can be solved with some clever links in various places.

+1. And, if it's not implied already: they don't need to be features of a graph view.

[jpellizzari]

Related to links, they should appear on the Applications table now when using explorer: #3248

[lasomethingsomething]

Saw this issue and cc'ing @bigkevmcd and @foot for alignment and awareness

[lasomethingsomething]

Per @squaremo: "Off the top of my head, and going on Darryl's comment in #2102, I think it's possible to trace Kustomizations and HelmReleases back to their original sources, and thereby get a kind of breadcrumb trail. It would be fairly easy to verify this in practice: create a repo that has HelmReleaseses that create Kustomizations that create HelmReleases and see if they are labeled so as to give you an unambiguous reverse path."

[foot]

Sad to see it go, I like the idea of a more global / navigable graph a lot.

graph TD
    A["gitrepo (flux-system)"] --> B["kustomization (flux-system)"]
    B --> C["helmrepo (podinfo)"]
    C --> D["helmrelease (pod-info)"]
    D --> E["deployment (podinfo)"]
    E --> F["replicaset (podinfo)"]
    F --> G["pod (podinfo)"]
    B --> D

Loading