[discuss] Upgrade Assistant and 3rd-party plugins

[afharo]

This issue is to discuss if we need to take any specific steps to tackle upgrades with 3rd-party plugins and what's needed to validate their compatibility with the next version.

Plugin manifest's kibanaVersion

Right now plugin developers can specify the versions their plugin is compatible with the kibanaVersion inside the kibana.json plugin manifest.

Are we using this field to warn the user in the Upgrade Assistant?

Use of deprecated ES APIs

Kibana exposes the same ES client to built-in plugins and 3rd-party ones. This means all the calls include the header x-elastic-product-origin: kibana. It will hide any use of the deprecated APIs by 3rd-party plugins as well. Is this a problem? Or are we OK given that the kibanaVersion should enforce different versions of 3rd-party plugins to different versions of the Stack?

Any other potential issues we may face and that I missed?

[elasticmachine]

Pinging @elastic/platform-deployment-management (Team:Deployment Management)

[elasticmachine]

Pinging @elastic/kibana-core (Team:Core)

[pgayvallet]

what's needed to validate their compatibility with the next version.

Basically, when using 3rd party plugin, they need to be upgraded during each Kibana upgrade.

From https://www.elastic.co/guide/en/kibana/current/kibana-plugins.html:

We cannot provide backwards compatibility for plugins due to the high rate of change. Kibana enforces that the installed plugins match the version of Kibana. Plugin developers must release a new version of their plugin for each new Kibana release.

Kibana will throw an error during plugin discovery if any 3rd party plugin does not match the exact current version (unless it uses the hacky internal kibana version):

kibana/src/core/server/plugins/discovery/plugin_manifest_parser.ts

Lines 159 to 165 in 52ee65b

	if (!isVersionCompatible(expectedKibanaVersion, packageInfo.version)) {
	throw PluginDiscoveryError.incompatibleVersion(
	manifestPath,
	new Error(
	`Plugin "${manifest.id}" is only compatible with Kibana version "${expectedKibanaVersion}", but used Kibana version is "${packageInfo.version}".`
	)
	);

Are we using this field to warn the user in the Upgrade Assistant?

Not that I'm aware of. AFAIK each plugin's version is only accessible / known internally by core, and we are not registering any deprecation associated with 3rd party plugins atm (we don't even have a third party plugin distinction anymore since the end of the KP migration, even if that could be added back)

Kibana exposes the same ES client to built-in plugins and 3rd-party ones. This means all the calls include the header x-elastic-product-origin: kibana. It will hide any use of the deprecated APIs by 3rd-party plugins as well. Is this a problem?

Unless we can find scenarios where the usage of deprecated APIs can cause harm to our system, I'd say no. My reasoning is that if a 3rd party plugin is broken or blocks Kibana from behaving correctly (as long as it doesn't introduce persisted data corruption), I don't think it should be our responsibility, given we're not providing any support on 3rd party plugins?

[lukeelmers]

if a 3rd party plugin is broken or blocks Kibana from behaving correctly (as long as it doesn't introduce persisted data corruption), I don't think it should be our responsibility, given we're not providing any support on 3rd party plugins

I agree we aren't under any obligation to "fix" this, since users should be able to trust that if a 3rd party plugin releases a new version that's compatible with the next Kibana release, it will have been tested and should work with the stated version.

That might mean that we have 3rd party plugins using deprecated APIs, but by the time any breaking changes are made, I would expect that to get caught and addressed by the plugin as part of introducing support for the new major version.

Also (anecdotally) in my experience most maintainers of the more popular 3rd party plugins do a pretty good job of checking release documentation for any API changes they need to make.

All that said, I do think that something like #120201 could provide value to 3rd party developers, by making it easier for them to test their own usage of deprecated APIs during development by removing the product header. But for end users, I'm not sure surfacing these in the UA is necessary: either a 3rd party plugin supports the version of Kibana you are upgrading to, or it doesn't and you need to wait on it to issue a new release.

[alisonelizabeth]

Sorry, late to the discussion.

Are we using this field to warn the user in the Upgrade Assistant?

I think @pgayvallet already covered this, but just to confirm - I'm also not aware of anything.

But for end users, I'm not sure surfacing these in the UA is necessary: either a 3rd party plugin supports the version of Kibana you are upgrading to, or it doesn't and you need to wait on it to issue a new release.

++ this makes sense to me as well.

[rudolf]

Based on the discussion it does not seem like this is something we want to action so closing to make it clear that we don't plan to work on this for 9.0