Fleet: define upgrade path for unsupported packages

[mtojek]

Hi Team,

we're trying to understand the following path:

If Kibana is upgraded from 7.16 to 8.x, and one or some of the installed packages are not compatible with 8.x, does Kibana try to find a resolution as part of the upgrade? (two possible scenarios: there is a newer version compatible with 8.x, or the package has been removed)

What is the current state and how is this use case covered?

cc @jen-huang @kpollich

[elasticmachine]

Pinging @elastic/fleet (Team:Fleet)

[joshdover]

What is the current state and how is this use case covered?

Currently, only 'managed' packages are touched at all by any automated upgrade process. These include system, fleet_server, elastic_agent, endpoint, apm, and synthetics. Our logic simply tries to install the most recent, compatible version if available. I'd need to dig more to understand what it will do if no compatible version is available, but for these few packages, that should never be the case.

For other packages, we will leave the assets installed as-is and do not make any modifications during upgrades. The user should be able to see this package as installed, even if no longer available in the registry. However they will not see any notifications in the UI about upgrades since none are available.

[mtojek]

Thanks, Josh, for responding.

For other packages, we will leave the assets installed as-is and do not make any modifications during upgrades.

Is there any plan or roadmap issue for upgrading other packages?

I'm also curious about the use case in which I upgraded the stack and it seems that only 7/10 packages are compatible with new Kibana. What should I do in this case? Is there any options like "unsupported/dangerous mode/force and install"?

[joshdover]

Is there any plan or roadmap issue for upgrading other packages?

I believe this is the main issue where this has been discussed: #72714

I'm not sure yet we have a driving use case for these upgrades, since I joined the team I've only discussed automatic upgrades in the context of the managed packages.

There are a few relevant bugs in this area:

• [Fleet][EPM] Upgrade rollback fails because the previous package is out of date #82088
• [Fleet] Handle packages not available anymore #74647

I'm also curious about the use case in which I upgraded the stack and it seems that only 7/10 packages are compatible with new Kibana. What should I do in this case? Is there any options like "unsupported/dangerous mode/force and install"?

There is at the API level, but none exposed in the UI today. The install endpoint accepts a force flag:

POST /api/fleet/epm/packages/<name>-<version>
{ "force": true }

I would be curious to learn more about why a package would need to be considered incompatible with a future version. Unless we're using a feature that has been removed by Elasticsearch (which is rare), I wouldn't expect there to be an upper-bound on the version compatibility for the vast majority of packages.

I'm also not sure that we would know that upper-bound until a feature is actually scheduled for removal. Do we have a way to add new constraints to an existing, potentially older, package version? If so, we may need to account for that in our caching logic on the Kibana side.

[mtojek]

I would be curious to learn more about why a package would need to be considered incompatible with a future version. Unless we're using a feature that has been removed by Elasticsearch (which is rare), I wouldn't expect there to be an upper-bound on the version compatibility for the vast majority of packages.

I'm thinking rather about edge cases like: a package owner didn't provide an update for a package to be compatible with new stack (at some point we may have packages owned by third-parties) or due to some other bug the old package simply doesn't work, but the new one would work perfectly (bug fixed?)

Do we have a way to add new constraints to an existing, potentially older, package version? If so, we may need to account for that in our caching logic on the Kibana side.

No, it isn't possible as released/delivered packages are idempotent. On the other hand we could deprecate a package (there is a task for this).