[Ingest Manager] Upgrade Package APIs #77779
Labels
Feature:EPM
Fleet team's Elastic Package Manager (aka Integrations) project
Team:Fleet
Team label for Observability Data Collection Fleet team
Background
For an external app to upgrade a package it is interested in, it has to perform the following actions:
GET /packages
to list the available packages, then filter the response done to the one they're interested inGET /packages/<package key>
to get the full information about the package including thelatestVersion
field to determine if an update existsThis could probably be simplified by adjusting the
/packages/endpoint-0.1.0
to:POST /packages/endpoint
- Installs the latest available endpoint packageGET /packages/endpoint
- Returns all information about the endpoint package (current version installed, and latest version available from the registry)POST /packages/endpoint/0.2.0
- Installs endpoint package version 0.2.0GET /packages/endpoint/0.2.0
- Gets the information about endpoint package version 0.2.0 (whether it is installed, and registry information)Having a bulk upgrade api could also be useful for the Ingest manager to handle automatically upgrading the default packages:
This would upgrade both the
endpoint
andsystem
packages.POST /packages
is already used for bulk install of uploaded packages:https://github.com/elastic/kibana/blob/master/x-pack/plugins/ingest_manager/server/routes/epm/index.ts#L87
https://github.com/elastic/kibana/blob/master/x-pack/plugins/ingest_manager/common/constants/routes.ts#L25
Related issues I could find:
#76438
#62479
#66777 (comment)
Phase 1 - Implement Bulk API
Implementation
The easiest way forward with the least sweeping code changes is probably to implement the bulk API. It would have the following implementation:
For each package in the
upgrade
array from the request bodyDoing a
greater than
version check will avoid unnecessary installations of a package that already has the latest version installed. This is useful because thebulk upgrade
API will be called each time a user navigates to a different package within the ingest manager UI and each time a user navigates to a different page in the Security Solution UI.Handling Errors
If installing a package failed, the bulk upgrade API would record the error and move on to the next package to upgrade.
Response
The bulk API response would be:
Or maybe:
Later Phases
Refactor the single package APIs to something like:
POST /packages/endpoint
- Installs the latest available endpoint packageGET /packages/endpoint
- Returns all information about the endpoint package (current version installed, and latest version available from the registry)POST /packages/endpoint/0.2.0
- Installs endpoint package version 0.2.0GET /packages/endpoint/0.2.0
- Gets the information about endpoint package version 0.2.0 (whether it is installed, and registry information)This would allow the Security Solution and other external apps that are only interested in upgrading a single package to leverage
POST /packages/<package name>
instead of using the bulk upgrade API.The text was updated successfully, but these errors were encountered: