Create Flux plugin

[joaquimrocha]

A Flux plugin would be very useful for all users of flux who would like a UI for it and who could also benefit from having it integrated in a generic K8s UI like Headlamp.

[monadic]

yes please

[ashu8912]

The progress on this is tracked here headlamp-k8s/plugins#75

The plugin should look for Flux installation on the Cluster and show different views related to Flux.

• Application List View is Done
• Application Detail View Lists basic detail about a Kustomization or a HelmRelease
• Application Detail View has Sync With Source and Sync Without Source action buttons
• Application Detail View has Suspend action button
• Application Detail View also lists The inventory and links them to the correct K8s resource view on Headlamp
• Source List View is Done
• Source Detail View shows basic detail About a GitRepository or OCIRepository or Buckets or HelmRepos and HelmCharts
• Source Detail View Allows suspending and resuming reconciliation
• Notification List View is done
• [] Notification Detail View is done
• Image Automation List View is done
• Image Automation Detail View shows basic details for Image Repo or Image Policies or Image Update Automations
• Flux Runtime View Lists all the flux related controllers and CRDs
• Flux Runtime shows the running version of flux

[kingdonb]

I've got this running in a cluster now:

looking good! I need to add some flux artifacts, there may be one or more possibilities for how to detect the Flux Runtime version. I am seeing a label on each of my controllers, for example:

  labels:
    app.kubernetes.io/component: helm-controller
    app.kubernetes.io/instance: cozy-fluxcd
    app.kubernetes.io/managed-by: flux-operator
    app.kubernetes.io/part-of: flux
    app.kubernetes.io/version: v2.3.0
    control-plane: controller
    fluxcd.controlplane.io/name: flux
    fluxcd.controlplane.io/namespace: cozy-fluxcd

Note the version:
app.kubernetes.io/version: v2.3.0 is a match for the installed version of FluxCD/flux2 itself

This is a managed flux, via flux-operator, so this may differ (?) from how it looks on a flux installed via flux boostrap or flux install - need to double check

[kingdonb]

So I have a declarative (HelmRepository/HelmRelease) YAML to install Headlamp with the Flux plugin now, and it's working, but:

There's the HelmRelease, it installed successfully, I can see the events at the top level, but clicking through to see the details of the HelmRelease results in an error:

I think it would be beneficial to plug it into a dev container or okteto CLI next, so we can iterate on the in-cluster version without building a new container every time we want to test a change... but I'm going to stop now because this is great progress, and the Flux dev meeting is in about 15 minutes, people will have gut reactions and feedback there I'm sure!

(fluxcd.io/community/#meetings if you want to join us, all the information is there)

[kingdonb]

I see the more centralized discussion is ongoing here:

headlamp-k8s/plugins#75

[absnmohammedsedex]

@kingdonb , thank you for introducing headlamp, I did the helm install and can see the cluster and other k8s objects. I have build the flux plug and it stuck at

headlampPluginBin path: /Users/abdulmohammed/.asdf/installs/nodejs/18.15.0/lib/node_modules/@kinvolk/headlamp-plugin/bin/headlamp-plugin.js
Checking if headlamp-plugin is up to date...
    @kinvolk/headlamp-plugin is up to date.
<i> [FileManagerPlugin] copied "./package.json" to "/Users/abdulmohammed/Library/Application Support/Headlamp/plugins/flux-plugin/package.json
<i> [FileManagerPlugin] copied "./dist/*" to "/Users/abdulmohammed/Library/Application Support/Headlamp/plugins/flux-plugin
Watching for changes to plugin...

Do you have any idea why it's doing so? I am using Mac, and currently port forwarding to connect to pod/service.

[kingdonb]

With the pod in a deployment, the plugin has to actually be installed in the pod. I just published (https://github.com/kingdonb/headlamp-flux-test) some manifests that I've been using to install headlamp on a local cluster, but I'm making some changes to try to get it to work on an openshift environment, I see #2226 is still in progress so I might have to wait to make more progress

I'll make a few separate configs, one for without openshift, so it's easier to follow my example

The short answer is if you build the plugin locally, you should try using it with a local headlamp (running on your mac) but I haven't tried that yet, been focusing on the in-cluster use case because I think it's what most people will want in the long run, especially flux users

[kingdonb]

The canary image I've included in https://github.com/kingdonb/headlamp-flux-test is updated now to catch up with the latest changes in headlamp-k8s/plugins#75

I'm testing it on a k3s environment and so far so good.

It installs into the default namespace, once you port-forward to it, it provides instructions on how to generate a token, basically:

k create token headlamp -n default

(Careful with that token, it has cluster-admin and can see everything across the whole cluster! Anyone who has access to the Kubernetes control plane port can exploit it, if you accidentally disclose it somehow.)

You should be able to use this to test Headlamp out locally on a kind cluster or similar, and provide feedback about whether the deployed Flux plugin is able to meet your needs or still missing some key features.

(Thank you for taking a look @absnmohammedsedex !)

I don't recommend deploying it anywhere important until the flux plugin is vetted a bit more thoroughly and published into the catalog. I am seeing some kind of error that I'm not sure how to get the details of, it looks like the "something went wrong" screenshot above. I see some errors in the browser console but I'm not able to interpret them.

If you want to see the Dockerfile I used to build, I also don't recommend adopting it for production, since you might want to use more plugins, and I haven't tested that, pretty sure it needs a bit more work for that, ... here is the branch I'm building:

https://github.com/kingdonb/plugins/tree/build-plugins-docker

It builds like this:

docker buildx build --push --platform linux/amd64,linux/arm64 -t kingdonb/plugins:canary .

I'll try iterating on this for a little while longer until I get a better idea of what's wrong, but I have limited time today, may not get all the way there. (Good luck!)

Edit: maybe the debugging experience would be better if I was testing it out locally...

[absnmohammedsedex]

@kingdonb thank you again.
I have tried using the Helm release with init container values, but the pod is stuck in a pending state as follows,

kl -n kube-system my-headlamp-567fc4bfdb-h49dp
Defaulted container "headlamp" out of: headlamp, headlamp-plugins (init)

[kingdonb]

It's likely pending because of a persistent volume claim that is unfulfilled, I had to change mine from ReadWriteMany to ReadWriteOnce but depending on your environment you may not have a CSI driver for storage classes at all