[FEATURE] fetch plugin based on version

[shahrokni]

perses/perses#1186

⚠️ BACKEND NEEDS TO BE UPDAED. EXPLAINED AT THE END OF DESCRIPTION

Different Plugins Versions and Registries

So far a plugin could be imported by its name only.

const remoteEntryURL = baseURL ? `${baseURL}/${name}/mf-manifest.json` : `/plugins/${name}/mf-manifest.json`;

The backend has recently introduced a feature by which multiple versions of the same plugin could be available.
This means if the consumer of the Plugin Registry provided the version and registry, the exact desired plugin could be loaded in the front!

To achieve the mentioned goal the new URL will carry the version and registry as well. If not provided by the consumer, the front uses the default values introduced by the backend which are latest and perses.dev

 const remoteEntryURL = baseURL
      ? `${baseURL}/${name}/${registry || DEFAULT_PLUGIN_REGISTRY}/${version || DEFAULT_PLUGIN_VERSION}/mf-manifest.json`
      : `/plugins/${name}/${registry || DEFAULT_PLUGIN_REGISTRY}/${version || DEFAULT_PLUGIN_VERSION}/mf-manifest.json`;

/*ESAMPLE FROM MY LOCAL MACHINE BY DEFAULT VALUES*/
/* http://localhost:3000/plugins/TimeSeriesChart/perses.dev/latest/mf-manifest.json */

⚠️ Backend needs to do

Backend should be adjusted to manage the new URL. I checked the backend and understood that at the moment the intercepted GET request is translated to the address of the files on the disk. Please take a look at (ui\endpoint.go)
I believe the following shared code should be adjusted for the new URL that I just explained.

if devEnvironment == nil {
		// In that case, we need to read the requested files from the file system.
		// The First thing to do is to replace the URL path with the local path of the plugin.
		localPath := strings.Replace(req.URL.Path, fmt.Sprintf("%s/plugins/%s", f.apiPrefix, pluginName), loaded.LocalPath, 1)

		// Then we just need to rely on the echo router to serve the file.

		// X-Content-Type-Options: nosniff is an HTTP response header that tells browsers: "Do not try to guess the content type — trust the Content-Type header I sent you."
		// Without it, browsers perform "MIME sniffing". For example, a file served as text/plain could be sniffed as text/html and executed as HTML, which could open the door to XSS attacks.
		// See https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Headers/X-Content-Type-Options
		c.Response().Header().Set("X-Content-Type-Options", "nosniff")
		return c.File(localPath)
	}

There is also a TODO comment in backend that I believe could to be addressed now

// TODO: These hardcoded values should be replaced once the frontend is able to manage multiple registries and plugin versions.
	// This suppose to update the plugin system first.
	// These hardocded values are matching the default behavior of the plugin system and it helps to keep backward compatibility.
	loaded, isLoaded := f.pluginService.GetLoadedPlugin(pluginName, pluginModel.LatestVersion, pluginModel.DefaultRegistry)
	if !isLoaded || !loaded.Module.Status.IsLoaded {
		logrus.Errorf("unable to find the plugin => %s", pluginName)
		return apiinterface.NotFoundError
	}

Checklist

• Pull request has a descriptive title and context useful to a reviewer.
• Pull request title follows the [<catalog_entry>] <commit message> naming convention using one of the
  following catalog_entry values: FEATURE, ENHANCEMENT, BUGFIX, BREAKINGCHANGE, DOC,IGNORE.
• All commits have DCO signoffs.

UI Changes

• Changes that impact the UI include screenshots and/or screencasts of the relevant changes.
• Code follows the UI guidelines.
• E2E tests are stable and unlikely to be flaky.
  See e2e docs for more details. Common issues include:
  • Is the data inconsistent? You need to mock API requests.
  • Does the time change? You need to use consistent time values or mock time utilities.
  • Does it have loading states? You need to wait for loading to complete.

[jgbernalp]

this could be undefined rather than empty.

[jgbernalp]

If we are changing the signature, probably is better to use an object

[jgbernalp]

maybe is better that the function can accept undefined values and will resolve the key, rather than adding logic to the parameters. Also it would be better to use an object so is more readable

[Nexucis]

actually the backend is storing the plugins in two different ways.

As an entry point in the plugin management, the plugins are registered using the plugin module name / plugin module registry. And then with this key, you have the list of version registered.

Then for the schema management per plugins, the key is the actual name of the plugin (not anymore the plugin module name) with the registry. Which give you access of a list of the various version supported for the given schema.

The same logic apply for the migration script.

But if you want to simplify this vision, the key / entrypoint in the plugin registry is the plugin module name + registry.

For example, if you consider the Prometheus plugin, it is actually a module that contains multiple plugins. So Prometheus is the name of the module and (for example) PrometheusTimeseriesQuery is one of the plugin provided by this module.

But for the frontend when getting the js files for the PrometheusTimeseriesQuery plugin, it will actually call the backend with the name of the module Prometheus and not PrometheusTimeseriesQuery because the js files of this particular plugin are mixed up with the rest of others plugin contained in the module. And the backend cannot give you exactly the files for this particular plugin, only for the module and then frontend is finding the one it is looking for.

Is it clearer or on the contrary even more fuzzy ?

[jgbernalp]

an object parameter will avoid this undefined, undefined fields

[Nexucis]

Thank you @shahrokni for updating the frontend regarding the plugin multi version management !

Indeed the backend will need to be updated at some point, but hopefully that should be as easy as to update the regexp

capturingPluginName = regexp.MustCompile(`/plugins/([a-zA-Z0-9_-]+)/?.*`)

to catch the registry and the version.

[jgbernalp]

We don't load individual plugins, we load the whole plugin module, which has specific plugin exports internally.

[jgbernalp]

IIUC from the backend, the default version is empty for backwards compatibility, which means the latest version.

[jgbernalp]

is this needed? the plugin versions are defined inside dashboards, if not defined it will use whatever is available in the backend.

[jgbernalp]

this will break existing plugins, we probably want this to be optional.

[Nexucis]

yeah this can be optional. It is the case in the equivalent go struct

[jgbernalp]

Not sure how this is handled in the backend, but this won't be a valid url path unless escaped. By default this is probably empty to use the core plugins

[Nexucis]

by default if it is empty, then the value is equal to perses.dev