Plugin pre installing and building

[revvysh]

I have been started using headlamp for my EKS cluster, and its really have become a good tool to explor the cluster. Kudos.

Recently i started using plugins and and found that all plugins are initialised in cluster using init containers with PVC (Persistent Volume Claims). Even though which is good and can have dynamically bringing plugins. Wonder how easy it would be to precompile and include the plugins also in the docker image.

Looking if we can have a standard procedure documented for building customer docker with custom plugins pre installed on the docker.

Please direct me if there is a documentation already available for the same.

[SegFault02]

I have been started using headlamp for my EKS cluster, and its really have become a good tool to explor the cluster. Kudos.

Recently i started using plugins and and found that all plugins are initialised in cluster using init containers with PVC (Persistent Volume Claims). Even though which is good and can have dynamically bringing plugins. Wonder how easy it would be to precompile and include the plugins also in the docker image.

Looking if we can have a standard procedure documented for building customer docker with custom plugins pre installed on the docker.

Please direct me if there is a documentation already available for the same.

we just mount config map with all custom plugins)

[ysaakpr]

Wouldnt that be so much for config maps to support, large enough js files to be added to config maps. I would prefer to use a custom build with added plugins prebuilt.

[ysaakpr]

Created a personal project with custom extra plugins built to the default image.

Achieved by editing the default container/build-manifest.json with links to the flux releases in plugins repository.

Let me know if anyone is intrested in any other plugins, until there is a real fix, i could maintain this by having all set of plugins installed by default.

Are there anyway, to hide the plugins in the UI for users who don't want it, even though its installed, something like, enable disable option?

[joaquimrocha]

We allow plugins to be enabled/disabled in the desktop version, the rationale being that if you have the UI being deployed for you as a service, it's probably not a good idea to be able to disable the plugins that the admins chose for it.
Maybe you have a use case for being able to still disable some plugins?
One thing I want to improve is how to pass configuration to the UI from a deployment/backend point of view. So we can do things like: Enabled plugins: X, Y, Z / User enableable: Y, Z
or something...

[ysaakpr]

Enabled plugins: X, Y, Z / User enableable: Y, Z ??
Enabled plugins Did you mean, installed plugins ? and Enableable means, these plugins the user can control the visibility to the the headlamp UI

[k8s-triage-robot]

The Kubernetes project currently lacks enough contributors to adequately respond to all issues.

This bot triages un-triaged issues according to the following rules:

• After 90d of inactivity, lifecycle/stale is applied
• After 30d of inactivity since lifecycle/stale was applied, lifecycle/rotten is applied
• After 30d of inactivity since lifecycle/rotten was applied, the issue is closed

You can:

• Mark this issue as fresh with /remove-lifecycle stale
• Close this issue with /close
• Offer to help out with Issue Triage

Please send feedback to sig-contributor-experience at kubernetes/community.

/lifecycle stale