[Fleet] Handle ES failures on template installation

[jonathan-buttner]

Describe the feature:

There are a couple of TODOs in the EPM template generation (both index template and component template) code to handle any errors returned from ES

here:

kibana/x-pack/plugins/ingest_manager/server/services/epm/elasticsearch/template/install.ts

Line 275 in 2d0106d

// TODO: Check return values for errors

and here:

kibana/x-pack/plugins/ingest_manager/server/services/epm/elasticsearch/template/install.ts

Line 319 in 2d0106d

// TODO: Check return values for errors

One solution would be to just wrap them in a try/catch and throw a Boom. This may cause installation of the rest of the required packages to fail though.

[elasticmachine]

Pinging @elastic/ingest-management (Feature:EPM)

[skh]

Strategy for error handling is here: #66688

In particular, we've been advised to move away from Boom.

[ph]

Could this be closed @skh @jfsiii @neptunian ?

[jfsiii]

@ph, @jonathan-buttner knows best what this is about but we are able to identify an ES error and include the reason in the HTTP response. See #76865

[skh]

The TODOs in that file are still there (moved to different lines now), marking code paths where return values need to be checked.

We should at least check if the corresponding errors can be triggered in tests, and add tests to verify the current error handling is ok.

[jonathan-buttner]

Yeah this ticket was just to track some of the TODOs in EPM. I agree with @skh, it'd probably be good to introduce some errors in the tests and see if we can handle the errors.

[jfsiii]

@skh @jonathan-buttner I updated the description to point to the new lines. Both of them are deal with communicating with Elasticsearch (callCluster). Can you help define what error behavior we want to assert?

The two things that come to mind are

• a) any errors from ES are thrown by these functions
• b) the errors result in specific HTTP failure status/response

Are there specific ES errors we want to test? Should there be different behavior for different errors beyond the HTTP status/response?

For (a) I see the testing as

• mock callCluster to throw an error (or specific errors)
• call installDataStreamComponentTemplates & installTemplate
• ensure they throw the given ES error(s)?

(b) is more challenging since installTemplate is one of several other functions called by installPackage, which is called by installPackageFromRegistry & installPackageByUpload. The installPackage* functions are called as a part of /setup & /epm/package. That's a lot of functions and side-effects.

Perhaps we could assert that given (a) the error given to defaultIngestErrorHandler (or perhaps other specific route handlers) results in the desired status & message?