Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Flux: Overview Page #79

Open
Aubermean opened this issue Sep 2, 2024 · 4 comments
Open

Flux: Overview Page #79

Aubermean opened this issue Sep 2, 2024 · 4 comments
Labels

Comments

@Aubermean
Copy link

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
Copy link
Contributor

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
Copy link
Author

Aubermean commented Sep 2, 2024

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.

@joaquimrocha
Copy link
Contributor

I think having an overview for the Flux plugin makes a lot of sense. Let's do that!
We are also very open to getting feedback on how to improve other views as well, so keep those coming. Kubernetes has a lot of data, so it's hard for us sometimes to understand exactly what to show by default. Having input from other Kubernetes users definitely helps.

@joaquimrocha
Copy link
Contributor

We are in the process of designing the overview page. Maybe it will take a couple of weeks.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

4 participants