[Fleet] Fix fleet_server_hosts value in fleet/settings API

[kpollich]

Summary

Resolve fleet_server_hosts from the new Fleet Server Host SO type instead of the settings SO.

Would like to add an integration test for this, but requires setting up a new "get settings" suite. Will push a follow-up commit.

Fixes elastic/fleet-server#2068

Checklist

• Unit or functional tests were updated or added to match the most common scenarios

[elasticmachine]

Pinging @elastic/fleet (Team:Fleet)

[juliaElastic]

🚀

[criamico]

I have a broader question about this change. Are we keeping the /settings endpoint route as it is?

I originally thought we wanted to deprecate it in favour of the new endpoints, since settings gives the idea of reading/editing all the possible settings (also outputs, etc..) and not only the hosts.

EDIT: I see from the description that other teams are using this endpoint, so my comment is intended on the long run rather than the immediate.

[kpollich]

I have a broader question about this change. Are we keeping the /settings endpoint route as it is?

I originally thought we wanted to deprecate it in favour of the new endpoints, since settings gives the idea of reading/editing all the possible settings (also outputs, etc..) and not only the hosts.

It's probably worth discussing, but it would make sense to do away with the singular /settings endpoint as we now have distinct resource types the drive Fleet's settings page:

• Fleet Server Hosts
• Outputs
• Agent Binary Download Sources
• (soon) Proxies

We no longer have a real use case for a unified /settings API as all the settings that drive this configuration experience are surfaced as their own, first-class API resources.

Still, this would be a breaking change, so we should work with other teams to determine an approach here. We'll also want to audit our client side code to make sure we're not relying on this settings API anywhere in Fleet's own codebase.

Probably something worth discussing in the Fleet API GA issue: #123150

[kpollich]

@elasticmachine merge upstream

[kpollich]

I think this is the right move to skip these tests - these are leftover from when we were using the /settings API to create new Fleet Server hosts. AFAIK this is no longer supported, as any Fleet Server Hosts within the Fleet settings saved object will be ignored. @nchaulet please correct me if I'm wrong here.

We'll probably want to remove this API altogether as part of the GA work.

[nchaulet]

Yes we probably want to remove these tests, and this API (at least the fleet_server_hosts) part should be removed as part of the GA work (we should already mark them as deprecated in the open API spec and point to new fleet server hosts endpoints)

[kpollich]

I update this telemetry collector to use the new Fleet Server Hosts model for its calculation instead of the settings SO.

[nchaulet]

Good catch 👍

[kibana-ci]

💚 Build Succeeded

• Buildkite Build
• Commit: 3e332f5

Metrics [docs]

Unknown metric groups

ESLint disabled in files

id	before	after	diff
osquery	1	2	+1

ESLint disabled line counts

id	before	after	diff
enterpriseSearch	19	21	+2
fleet	59	65	+6
osquery	108	113	+5
securitySolution	440	446	+6
total			+19

Total ESLint disabled count

id	before	after	diff
enterpriseSearch	20	22	+2
fleet	67	73	+6
osquery	109	115	+6
securitySolution	517	523	+6
total			+20

History

• 💔 Build #86827 failed 5f27006
• 💔 Build #86751 failed f3fac54
• 💔 Build #86636 failed cfc50dd

To update your PR or re-run it, just comment with:
@elasticmachine merge upstream

cc @kpollich