Application Detail View

[JamWils]

We want to revisit the application detail view table and see how we can show information in a more comprehensive way that is easier to consume for both platform engineers and application developers.

The number one challenge is when you get to a production system you can have hundreds of pods per deployment and with Flux you can have any number of deployments. This makes the existing table view unwieldy when we present the information as the user will need to scroll thousands of rows to understand the information.

Second, we want to make this information easier to present across the application. For example, we want the user to have a similar experience when they are viewing deployments from their applications detail view, the pipelines view, or progressive delivery. The idea of an application should be consistent and noticeable at first glance.

Let's play around with various ideas on how we can show this information succinctly. I think it will take a few iterations, but we will make progress.

In my opinion, we should start with one view in Argo CD that displays information really well and that is the health view.

There are quite a few things out of scope. We don't need to worry about CPU and memory. We don't need to copy headers or button styles. However, notice how it succinctly shows the health of the pods in a deployment. We need to move closer to a more condensed design.

If we were to create widgets then what can we create them for? Showing a deployment, replica sets, and all of its pods? Can we show a third party install with all of the CRDs listed? What about workspaces?

There is a lot to work with. Maybe at first we just start with the deployments and then we can have a separate table for all other objects.

[LappleApple]

@jpellizzari Have you ever seen this issue? I just found it. Liz suggested that I ping you in case you have feedback/opinions.

I was talking to @makkes earlier today and we touched upon the topic of consolidating UI views. Applications view came up in our chat, as it's also part of the discussion about the Pipelines UI/work. Maybe we should chat in a week or two about the UI user flow.

cc'ing @mmoulian who's going to start working on the Pipelines UI design next week.

[jpellizzari]

@LappleApple I saw a design that resembled it a while back.

The Argo view shows Pod status by Node, which is fairly trivial in a single cluster context.

The WeGO drawing shows Pod status by Application across clusters (presumably). Given that an Application can be a HelmRelease or Kustomization, an Application can therefore be any object or objects reconciled by those top-level objects.

The drawing assumes that we select Deployments out of an Application, then show the status of Pods that are "downstream" (note that it goes Deployment -> ReplicaSet -> Pod).

I am fairly confident our existing cluster querying mechanism would buckle under the weight of this fan-out to each cluster/namespace pair. I suggest we create a detailed sequence diagram that walks through the steps for fetching all this data.

Else, we can try to utilize the new explorer backend for this, but I would imagine there are some feature gaps that would need to be filled.

[LappleApple]

Also found #1620 (includes link) proposing filtering options

[mmoulian]

If it serves as information. This is one of the prototypes I worked on with James for this issue:

https://github.com/weaveworks/weave-gitops-enterprise/assets/95616291/a9affdf6-a2b3-43bc-8f78-2cc475bd2ca1

[LappleApple]

Thanks for sharing, @mmoulian. cc'ing @yiannistri @squaremo @steve-fraser @darrylweaver for awareness -- guys, if you have any feedback to share on Manuela's prototype for the Applications view above, please do so here. (I wonder if we could share some version of this with prospects to get input, as we plan to do with the Pipelines mockup?)

This is not to say that we'll go straight to implementation of this view. But we have it available to draw ideas and inspiration from, so let's talk about it—what we like, don't like, don't see, don't think is possible...

[LappleApple]

See also: https://github.com/weaveworks/weave-gitops-interlock/issues/364, where @darrylweaver writes:

Should the applications UI just be a table of entries, or should we display a hierarchical view? A hierarchical view would have lots of advantages to understanding the way that weave gitops works. The view could start with Cluster, then the top level Kustomization: flux-system for each cluster. Other objects would be displayed under their parent objects to show the view like flux tree view.

For example something like this:

Kustomization/flux-system/flux-system ├── CustomResourceDefinition/alerts.notification.toolkit.fluxcd.io ├── CustomResourceDefinition/buckets.source.toolkit.fluxcd.io ├── CustomResourceDefinition/gitrepositories.source.toolkit.fluxcd.io ├── CustomResourceDefinition/helmcharts.source.toolkit.fluxcd.io ├── CustomResourceDefinition/helmreleases.helm.toolkit.fluxcd.io ├── CustomResourceDefinition/helmrepositories.source.toolkit.fluxcd.io ├── CustomResourceDefinition/kustomizations.kustomize.toolkit.fluxcd.io ├── CustomResourceDefinition/ocirepositories.source.toolkit.fluxcd.io ├── CustomResourceDefinition/providers.notification.toolkit.fluxcd.io ├── CustomResourceDefinition/receivers.notification.toolkit.fluxcd.io ├── Kustomization/cert-manager/cert-manager │ ├── Namespace/cert-manager │ ├── HelmRelease/cert-manager/cert-manager ├── Kustomization/cert-manager/clusterissuer │ └── ClusterIssuer/letsencrypt-prod ├── Kustomization/flux-system/app-templates │ ├── GitOpsTemplate/default/app-podinfo-chart-and-pipeline │ ├── GitOpsTemplate/default/deploy-podinfo-chart │ ├── GitOpsTemplate/devteam1/app-podinfo-chart-and-pipeline-devteam1 │ └── GitOpsTemplate/devteam1/deploy-podinfo-helmchart-with-container ├── Kustomization/flux-system/aws-secretstore │ └── ClusterSecretStore/aws-secretstore ├── Kustomization/flux-system/capi-bootstrap │ ├── ConfigMap/default/calico-crs-configmap │ ├── ConfigMap/default/cilium-addon │ ├── ConfigMap/devteam1/cilium-addon │ ├── ClusterResourceSet/default/awssm-crs │ ├── ClusterResourceSet/default/calico-crs │ ├── ClusterResourceSet/default/crs-cilium │ ├── ClusterResourceSet/devteam1/crs-cilium │ ├── ClusterBootstrapConfig/default/capi-gitops │ ├── ClusterBootstrapConfig/default/cilium-cluster-bootstrap │ ├── ClusterBootstrapConfig/devteam1/capi-gitops │ └── ClusterBootstrapConfig/devteam1/cilium-cluster-bootstrap ├── Kustomization/flux-system/capi-profiles │ ├── GitRepository/flux-system/podinfo-app │ ├── HelmRepository/flux-system/app-charts │ ├── HelmRepository/flux-system/isovalent-charts │ └── HelmRepository/flux-system/weaveworks-charts

This would allow us to have a more sophisticated view that makes it much easier to understand the way that flux objects are managed in the repository. It would also make it much easier to troubleshoot issues.

[darrylweaver]

So, the mockup above looks more densely packed with information which is a big plus. What I don't see is any improvement in traceability. I most definitely want to go from any object and find out how it was deployed to the cluster, by tracing back to it's source. If I can have that combined into the views of each application so I can trace how it was deployed by clicking a link to the previous object, I would be very happy.

Specifically, right now, you cannot trace back a HelmRelease to a Kustomization that deployed the HelmRelease CR. But the data is in the labels on the HelmRelease object and we show it under the details of the Kustomization.

So, you can trace forwards from a Kustomization, but you get to a dead end going backwards from a HelmRelease.

[jpellizzari]

would be displayed under their parent objects to show the view like flux tree view.

For example something like this: Kustomization/flux-system/flux-system ├── CustomResourceDefinition/alerts.notification.toolkit.fluxcd.io ├── CustomResourceDefinition/buckets.source.toolkit.fluxcd.io ├── CustomResourceDefinition/gitrepositories.source.toolkit.fluxcd.io ├── CustomResourceDefinition/helmcharts.source.toolkit.fluxcd.io ├── CustomResourceDefinition/helmreleases.helm.toolkit.fluxcd.io ├── CustomResourceDefinition/helmrepositories.source.toolkit.fluxcd.io ├── CustomResourceDefinition/kustomizations.kustomize.toolkit.fluxcd.io ├── CustomResourceDefinition/ocirepositories.source.toolkit.fluxcd.io ├── CustomResourceDefinition/providers.notification.toolkit.fluxcd.io ├── CustomResourceDefinition/receivers.notification.toolkit.fluxcd.io ├── Kustomization/cert-manager/cert-manager │ ├── Namespace/cert-manager │ ├── HelmRelease/cert-manager/cert-manager ├── Kustomization/cert-manager/clusterissuer This would allow us to have a more sophisticated view that makes it much easier to understand the way that flux objects are managed in the repository. It would also make it much easier to troubleshoot issues.

I'll leave one feasibility comment here: the Flux CLI is using recursion to build that view, and the CLI assumes a single cluster and single namespace, which guarantees some level of performance.

In the EE UI, that will not scale across clusters, nor will it work with our current Explorer backend architecture. We currently have child objects in the context of a single Application for this reason.

It is possible we could add some sort of graph lookup feature, but it would be a fairly substantial effort.

[darrylweaver]

It would not be for multi-cluster. Only for each cluster and be a replication of the flux tree view. I would be very surprised if this is possible in the flux CLI and not possible in the expensive commercial product.

[jpellizzari]

It would not be for multi-cluster. Only for each cluster and be a replication of the flux tree view. I would be very surprised if this is possible in the flux CLI and not possible in the expensive commercial product.

In a single cluster context it might work. The views I have seen include cross-cluster context, so just wanted to call that out here.

[mmoulian]

This is the last prototype in Figma:

https://github.com/weaveworks/weave-gitops-enterprise/assets/95616291/71e9bc2e-3e04-402a-ac3f-ffdba38e094d

It was built with this data: