Support input packages

[mtojek]

Meta-issue: elastic/package-spec#319

Blocker: elastic/package-spec#328

This PR modifies the Package Registry to support "input packages".

Changes:

1. Use sql_input as test package.
2. Add missing fields to "package index" API method.
3. Filter by "type" with /search API method.
4. Regenerate expected test results.

[elasticmachine]

💚 Build Succeeded

the below badges are clickable and redirect to their specific view in the CI or DOCS

Expand to view the summary

Build stats

• Start Time: 2022-05-25T11:59:06.268+0000

• Duration: 5 min 12 sec

Test stats 🧪

Test	Results
Failed	0
Passed	158
Skipped	0
Total	158

🤖 GitHub comments

To re-run your PR in the CI, just comment with:

• /test : Re-trigger the build.

[jsoriano]

What are old versions of Kibana do with packages that are not integrations?

Should we filter by type: integration when no type is passed? and maybe have a type: all to list all packages.

Or maybe this is a point where we should start versioning the API?

[mtojek]

and maybe have a type: all to list all packages.

I wouldn't like to design an API that won't be used by Fleet at all (KISS).

Should we filter by type: integration when no type is passed?

That would be counter-intuitive, you want to search for packages, but for some historical reason, the /search filters some of them. I would only go with that option to prevent any problems on the Fleet side.

Or maybe this is a point where we should start versioning the API?

It's always a good practice to version it, but not sure if this is a "dead end" to introduce versioning or if we just enable another GET parameter.

[jsoriano]

Well, then going back to the first question, what are current/old versions of Kibana going to do with packages that are not integrations?

[mtojek]

Passing the question to @joshdover.

[joshdover]

This seems like something that could easily be tested manually without code-level knowledge of Fleet. That would be how I test this personally.

[mtojek]

Sounds like a good idea, but, to be honest, I wouldn't like to block this PR until that happens.

[jsoriano]

Ah yeah, I didn't want to mean that 🙂 But this may delay declaring input package as GA in the spec.

[jlind23]

@mtojek I would say that each new input package should start with a kibana version constraints higher or equals to 8.3 which should then do the trick isn't it?

[mtojek]

Yes, Julien, that's the idea. Just waiting for the confirmation/approval from @joshdover.

[joshdover]

Kibana version constraint enforced by package-spec SGTM, agreed it can be done as a follow up.

[jsoriano]

Looks good, waiting for the discussion about backwards compatibility with Kibana/Fleet.

[mtojek]

As the input-type spec has been released, I suppose that this is the next task to be reviewed/merged.

[jlind23]

LGTM