docs: fix bad link in plugin dev docs

[kingdonb]

This is a broken reference in the docs.

(Can anyone let me know if this doc is outdated before I invest a bunch of time and find out it doesn't work?)

I won't hold this PR up by marking it as a draft, because the link is definitely broken, but if the doc is outdated and that's why the reference is bad, then maybe we shouldn't merge it. (I'll get around to building headlamp today with flux plugin that's in development, if the documents are good, but ...)

[kingdonb]

FWIW, I am stuck, trying to build a plugin locally or in a dockerfile results in a failure.

Lots of ModuleNotFound errors:

ModuleNotFoundError: Module not found: Error: Can't resolve 'elkjs'
ModuleNotFoundError: Module not found: Error: Can't resolve 'react-i18next'
...

I am on a NodeJS 20 runtime locally, NodeJS 18 in the dockerfile (adapted from the example, that uses NodeJS 16) - I think the result is the same on either one.

I can try with a simpler plugin to start, but if someone is available to talk me through it - or if a more recent walkthrough of plugin building is already published somewhere, I'd be very appreciative of a link!

[joaquimrocha]

@kingdonb Thanks. For testing a plugin, the fastest way is just to have it locally and test it with the desktop app. This involves having the plugin repo cloned, then running npm i and npm start, similar to creating a plugin:
https://headlamp.dev/docs/latest/development/plugins/building#creating-a-new-plugin

[joaquimrocha]

ModuleNotFoundError: Module not found: Error: Can't resolve 'elkjs'
ModuleNotFoundError: Module not found: Error: Can't resolve 'react-i18next'
...

Sorry for the obvious question, but did you run npm install? cc/ @ashu8912 maybe you can follow up.

[kingdonb]

I can't run it locally, I am setting up a collaborative environment for me, @stefanprodan, and @ashu8912 - it has to run in the cluster. No, I didn't run npm install that will probably help 😅 and that might have been in the very short list of things that Ashu mentioned, but I got lost somewhere between "you should run it locally" and the blog post about how to build it into a container.

I was going by the Dockerfile in the blog, we should update the blog so it works! :)

[kingdonb]

following those steps, including npm start I was able to get the plugin building for production locally at least.

I'll bang on it a bit longer until I figure out what's missing from the blog, there are only a few places where "npm install" could go so maybe it will be an easy fix

[joaquimrocha]

@kingdonb thanks. I've just opened #2257

[kingdonb]

I landed on:

FROM docker.io/library/node:18@sha256:d0bbfdbad0bff8253e6159dcbee42141db4fc309365d5b8bcfce46ed71569078 as builder

WORKDIR /headlamp-plugins

COPY ./flux-plugin /headlamp-plugins/flux-plugin

RUN mkdir -p /headlamp-plugins/build

RUN cd /headlamp-plugins/flux-plugin && npm install

# Build the plugin
RUN npx @kinvolk/headlamp-plugin build /headlamp-plugins

# Extract the built plugin files to the build directory
RUN npx @kinvolk/headlamp-plugin extract /headlamp-plugins/ /headlamp-plugins/build


FROM alpine:latest

# Copy the built plugin files from the base image to /plugins directory
COPY --from=builder /headlamp-plugins/build/ /plugins/

CMD ["/bin/sh -c 'mkdir -p /build/plugins && cp -r /plugins/* /build/plugins/'"]

I think there's a better formula because it seems like you will need to run npm install for each plugin this way, but my skepticism about if this would even work seems to have been overblown, I was expecting the resulting image to be hundreds of megabytes, and it's only 10.8MB 👍

Will spend a bit more time testing this and see what I can come up with. Next step for now is to push the image somewhere and see if I can get this running in the cluster.

[joaquimrocha]

FWIW, now that our headlamp-plugin command can install plugins from ArtifactHub, in the future we will improve how the images can be built when the plugins are published to ArtifactHub (not the case with this one, but still).

[kingdonb]

Macbook with Apple Silicon built the plugin image and the cluster is x86_64, so that was another obstacle I had to quickly overcome, an exec format error in the initContainer, which was of course no big deal, I've done all that before:

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

Now it's running in the cluster, the rest of the details in the blog post were fine. (Leaving this breadcrumb for anyone who is currently following along, between now and whenever we are able to update + fix the blog post with those missing details.)

I will go back down the stack and start nailing these things down in my fork, add some declarative artifacts, GHA workflows, so we can reproduce this easily in the future and iterate development until everyone agrees we can release this plugin (ref: #1872) - note the canary image is NOT intended to be used for production 😅

(is there a process for installing plugins in production that I missed, or is it click-driven, as they go into a persistent volume?)

This might have something to do with the artifacthub note you just mentioned - I would expect to be able to make a list of plugins to preinstall in the helm values, but maybe that is not how it's intended to work.

Are end users expected to install a collection of plugins from a named maintainer, or manage their own plugins image? Maybe there are multiple intended paths, (mainly depending I guess on whether you have someone on the payroll developing a plugin in your organization, or not)

I am working through the authentication docs now, generate a service account token first, configure for OIDC with Dex next - I'm hopeful that it worked, because it is in fact running now 🎉

[kingdonb]

Will continue the discussion in #1872