headlamp-k8s / plugins

Official plugins of the Headlamp project
https://headlamp.dev/
Apache License 2.0
8 stars 2 forks source link

Flux: Overview Page #79

Open Aubermean opened 1 week ago

Aubermean commented 1 week ago

Cluster and Workloads navigation menus starts with a view that provides a sort of umbrella overview of things.

It would be ideal if Flux has something similar, to provide a UI to the ever so helpful flux get all -A --status-selector ready=false.

This way, like in Events where you can quickly filter to see only the 'issues', you can quickly troubleshoot anything that is failing.

It means that instead of clicking Flux and being taken to Applications, you will be taken to a view not visible as a submenu. Just like Cluster and Workloads:

image

It could also do something like flux check and provide version information, warn if Flux is not bootstrapped to the cluster, etc.

❯ flux check
► checking prerequisites
✔ Kubernetes 1.31.0 >=1.28.0-0
► checking version in cluster
✔ distribution: flux-v2.3.0
✔ bootstrapped: true
► checking controllers
✔ helm-controller: deployment ready
► ghcr.io/fluxcd/helm-controller:v1.0.1
✔ image-automation-controller: deployment ready
► ghcr.io/fluxcd/image-automation-controller:v0.38.0
✔ image-reflector-controller: deployment ready
► ghcr.io/fluxcd/image-reflector-controller:v0.32.0
✔ kustomize-controller: deployment ready
► ghcr.io/fluxcd/kustomize-controller:v1.3.0
✔ notification-controller: deployment ready
► ghcr.io/fluxcd/notification-controller:v1.3.0
✔ source-controller: deployment ready
► ghcr.io/fluxcd/source-controller:v1.3.0
► checking crds
✔ alerts.notification.toolkit.fluxcd.io/v1beta3
✔ buckets.source.toolkit.fluxcd.io/v1beta2
✔ gitrepositories.source.toolkit.fluxcd.io/v1
✔ helmcharts.source.toolkit.fluxcd.io/v1
✔ helmreleases.helm.toolkit.fluxcd.io/v2
✔ helmrepositories.source.toolkit.fluxcd.io/v1
✔ imagepolicies.image.toolkit.fluxcd.io/v1beta2
✔ imagerepositories.image.toolkit.fluxcd.io/v1beta2
✔ imageupdateautomations.image.toolkit.fluxcd.io/v1beta2
✔ kustomizations.kustomize.toolkit.fluxcd.io/v1
✔ ocirepositories.source.toolkit.fluxcd.io/v1beta2
✔ providers.notification.toolkit.fluxcd.io/v1beta3
✔ receivers.notification.toolkit.fluxcd.io/v1
✔ all checks passed

As well as flux stats for a quick overview of qty of running/failing/suspended reconcilers.

❯ flux stats
RECONCILERS             RUNNING FAILING SUSPENDED   STORAGE
GitRepository           2       0       0           219.7 KiB
OCIRepository           0       0       0           -
HelmRepository          0       0       0           -
HelmChart               0       0       0           -
Bucket                  0       0       0           -
Kustomization           22      1       0           -
HelmRelease             0       0       0           -
Alert                   0       0       0           -
Provider                0       0       0           -
Receiver                0       0       0           -
ImageUpdateAutomation   1       0       0           -
ImagePolicy             9       4       0           -
ImageRepository         9       2       0           -

75

mgalesloot commented 1 week ago

The current version is still very much datadriven. Your suggestion is spot on, we need to focus on the use cases. In my experience the monitoring use cases are the most valuable. That means that the Flux plugin should provide an overview, with a focus on issues. I am not so sure if a Table View with kustomizations in several pages is the right way in that respect. Weave Gitops showed all kustomizations and helmreleases in a long list with errors on top. I feel that is a better approach.

Aubermean commented 1 week ago

The current version is still very much datadriven. Your suggestion is spot on, we need to focus on the use cases. In my experience the monitoring use cases are the most valuable. That means that the Flux plugin should provide an overview, with a focus on issues. I am not so sure if a Table View with kustomizations in several pages is the right way in that respect. Weave Gitops showed all kustomizations and helmreleases in a long list with errors on top. I feel that is a better approach.

The approach Headlamp has chosen is to generally divide things to one table per page. Since you can flick between pages with the namespace filter maintained, it makes navigation a pleasure.

Having to click to a page and then scroll to see where the second or third table starts, is adding steps for no reason, and makes it hard to flick between two pages/views...

If you look at the Configuration navigation menu, the dropdown has many options. Things like Priority Classes and Runtime Classes are divided, even if the tables are closely related or not hundreds of pages long. This, in my opinion, was an intentional design choice.

Screenshot 2024-09-02 at 8 03 26 PM

In terms of Weave Gitops approach, this is similar to what my feature suggestion was I think? Similar also to how the Cluster or Workloads overview page looks. This would mean that submenu navigation items can be dedicated to single tables as brought up in #78, following the existing example set by Headlamp.