[Fleet] Search packages based on available features

[jsoriano]

The different serverless offerings are going to have different sets of features, controlled from their configuration (available here).

EPM shouldn't try to install packages that require features that are not available on its kibana deployment, for this, it can request the registry only the set of packages it supports.
EPM will need to have a way to discover what features Kibana is supporting. There may be different options for this (having hard-coded lists, discovering them from settings, having a registry where enabled plugins can register themselves...).

Blocked till these issues are resolved:

• Definition of package requirements as capabilities is discussed in [Change Proposal] Add new field for dependency on stack capabilities package-spec#560.
• New parameter to filter out packages depending on capabilities added to the registry in Support search based on capabilities package-registry#1051.

[elasticmachine]

Pinging @elastic/fleet (Team:Fleet)

[nchaulet]

@jsoriano @mrodm while playing with capabilities filtering it seems that if a previous package without capabilities is available it will be returned it is expected and does it will work for what we try to achieve, for example:
With a kibana without apm capibilities, I have a package 1.0.0 without capabilities and a package 1.1.0 with capabilities apm, the package registry will return the package 1.0.0 it is what we expect?

[mrodm]

@jsoriano @mrodm while playing with capabilities filtering it seems that if a previous package without capabilities is available it will be returned it is expected and does it will work for what we try to achieve, for example:
With a kibana without apm capibilities, I have a package 1.0.0 without capabilities and a package 1.1.0 with capabilities apm, the package registry will return the package 1.0.0 it is what we expect?

What is the query used in this test ?
What version of the package-registry are you using ? Are you building a new docker image from main branch ?

[nchaulet]

What is the query used in this test ?
What version of the package-registry are you using ? Are you building a new docker image from main branch ?

I was using a local package registry for my test from the main branch and using ?capabilities=apm,... the filitering seems to work as the version 1.1.0 is correctly filtered but we still have the package as the version 1.0.0 do not have capabilities condition, I am wondering how this will work when we add capabilities to packages.

[mrodm]

Are you using also in the query all=true? @nchaulet
I think if all=true is set, it is expected to have that other version 1.0.0 also in the response. cc @jsoriano

If the parameter is included, packages included in response will be packages:

Without any capability condition.
When they have a capability condition, the ones whose required capabilities are included in the parameter.

[nchaulet]

I am not using all=true no, I am querying like this http://localhost:8080/search?kibana.version=8.8.2&capabilities=apm

[mrodm]

Ok, I think I misunderstood this.
After talking with @nchaulet offline, there is just one package in the response.

At first, it would be what it has been implemented for that.

For instance, it was added a test where the capability no matched with any package:
https://github.com/elastic/package-registry/pull/1054/files#diff-528d9e85e773a15ba856453da66fca04a8d07d3e4350ba36e4625bd828e329a1R388-R396

In that case, the packages that do not contain capabilities are returned. Package Registry would also add previous versions of a package that do not contain capabilities.

Maybe to not show some packages at all, it should be used spec.min or spec.max? @jsoriano

[jsoriano]

while playing with capabilities filtering it seems that if a previous package without capabilities is available it will be returned it is expected and does it will work for what we try to achieve, for example:
With a kibana without apm capibilities, I have a package 1.0.0 without capabilities and a package 1.1.0 with capabilities apm, the package registry will return the package 1.0.0 it is what we expect?

This is expected.

Maybe to not show some packages at all, it should be used spec.min or spec.max? @jsoriano

Correct, once all features are in place, packages will have to "opt-in" for serverless by using Package Spec v3.

[nchaulet]

Correct, once all features are in place, packages will have to "opt-in" for serverless by using Package Spec v3.

@jsoriano So we expect Kibana to query the package registry with spec.min:3 after everything is in place?

[juliaElastic]

@jsoriano Do you think there is value in QA source testing this with test packages (as described here ) or should we wait for actual packages to enable capabilities?

[juliaElastic]

@amolnater-qasource After checking with the team, we expect to have the first packages to test with in about 2 weeks, an email was sent out to package developers to enable it. We can check again in 2 weeks to see if this is available, you can keep it in for 8.11 testing probably.

[amolnater-qasource]

Thank you for the update @juliaElastic

[jsoriano]

Correct, let's wait to have some packages in place. Thanks!