Proposal: package validation API endpoint

[ycombinator]

IIUC the code for the package registry is the ultimate source of truth of what constitutes a valid package definition. If so, it would be nice if the registry service could expose an HTTP API endpoint for validation. It would take as input the entire package (as an archive file) and return success of a list of validation errors.

By centralizing the validation rules for a package in the package registry code and offering validation as a service, multiple tools could provide validation without having to reimplement the rules and keep them in sync. Two such tools that come to mind right now are:

• the elastic-package validate command: Command: lint the integration elastic-package#5
• when users are able to upload packages via Kibana: [Fleet] Allow to install a package without the registry. kibana#70582
• package storage or package registry itself - a package should not be accepted unless it's valid

[ycombinator]

cc: @ruflin @mtojek @ph (not sure who else to tag as relevant; feel free to add as you see fit!)

[mtojek]

I think I would go first with your idea for writing down the package definition, spec and others. Then we can go with updating the package-registry and elastic-package to pick it up. Maybe the validation code should be part of this common place?

Another approach - make the Elastic Package not only the tool, but also the official repository defining the spec. It can also contain package validation logic and others.
Package Registry can use the logic to validate packages and also expose the validation of archives over HTTP.

Personally I would keep the validation in some library, which can be exposed over the HTTP, but wouldn't keep it inside the Package Registry (separation of concerns). Exposing as web services implies additional action items to measure performance, bottlenecks, security threats and others.

[ycombinator]

@mtojek thanks for weighing in.

I was concurrently having this discussion with @exekias in our 1-1 and his thoughts are very much in line with yours: create a repo for the spec first, and package it as a library which could be embedded in tooling. Later we can consider using the library within the package registry to provide validation as a service.. I also just had a 1-1 with @andresrc in which we also discussed this and he's also +1 for the spec repo idea.

So without further ado, I'm going to create this repo (initially as private but with the intention of it being public) and notify stakeholders (internal for now) about it.

[ruflin]

++ on the plan. But I would make it public directly.

[jlind23]

[Clean up] Closing this as outdated, will reopen if required.