Create a settings/plugin area for managing plugins

[joaquimrocha]

Current situation

We can load plugins in desktop and in-cluster, and they are listed as well by an API endpoint. However, we don't show any info for the user or any way to manage the plugins (managing, as in enable/disable/remove them, would only be available in the desktop apps, not the in-cluster deployments).

Impact

Users/admins are not easily aware of what plugins are installed.

Ideal future situation

We have a settings area (#16 ) which has a plugins section. In this section we can see which plugins are installed and their basic info (we could expose creator, description, etc.).

In the desktop mode: users can disable or remove plugins. If plugins have options, they could be changed here.

[illume]

Some notes I wrote before about covering some different topics regarding a plugins management flow...

Enable and disable plugins for Desktop

The user is presented with the enabled plugins.

• see which plugins are enabled
• see when new plugins are added
• see when plugins change
• compatible versions of plugins

Only on Desktop, and only for user supplied plugins... not ones bundled with the app.

Mockup of dialog

# Enabled Plugins

enable  |  plugin name  |  approval date   |  checksum  |  first seen    |  Compatible
[x]     | pod-counter   | 2022/05/12 ...   | 12FACE...  | 2022/05/12 ... | 🗸
[ ]     | changelogo    |                  | BDEAD...   | 2022/05/18 ... | 🗸
        | changefooter  |                  | BDEAD...   | 2022/05/18 ... | ✘ v0.12.1

The idea is to show the screen when a plugin is (created, updated, or deleted). When a plugin changes or is added, the new or changed plugins are not executed until the user

Desktop plugin security.

The user data folder is usually writable, and it's possible to run a plugin in the context of an authorized Headlamp that may not work from the command line. To layer some defense from this direction, a way for Desktop Headlamp to get permission would be useful. Keeping it simple with an approved list "[(plugin filename, checksum, approvalDate, firstSeen), ...]".

Store in Local Storage

Where should this enabled-plugin-data be stored? In the window.localStorage('headlamp-plugin-state'). This should by default not be easily changed by a local user. If the browser is sandboxed, then this data should not be able to be changed from the local system.

Compatible versions of headlamp

To see if the plugin is compatible with a version of headlamp we could use the version specified in the package.json. This package.json could also be used to get a plugin name, and description. However, currently the package.json is not distributed with the plugin. Should the entire package.json just be copied? Or should only used data be copied. Should it be compiled into the main.js file somehow (with webpack)?

[joaquimrocha]

Here is the mockup from Tejas showing the list of plugins. Please keep into account that the origin is likely not needed at the moment just because we don't have its concept yet. Likewise, maybe a first version of this view doesn't need to support enabling/disabling plugins and can just show the ones we have as they're always enabled by default.

Any info we may want to add like compatibility, checksums, etc. as @illume added in his ascii table should be added in a similar style.

[joaquimrocha]

This is available in main now.