[Fleet] add support for fleet server urls

[nchaulet]

Summary

Resolve #89442

Allow to configure Fleet server urls, (still support Kibana url) when Fleet server url is configured this settings will be used instead of the Kibana url.

The removal of the Kibana url will be done in a following PRs once all of our CI, e2e tests run Fleet server.

UI Changes

The UI implement the new design from here #94624

• there is some help text around the field and the fields are full width
• the save button is only active if there is some change
• We now have a confirmation modal step

How to tests

You can test the UI, and that the policy generated contains fleet.hosts the end to end tests with fleet server is a little complicated now and I am trying to have easier way to run fleet server locally

[elasticmachine]

Pinging @elastic/fleet (Team:Fleet)

[ruflin]

This is great, we should add it in more place to make the cleanup easier and not forget things.

[blakerouse]

I have tested this change locally with my changes to Elastic Agent (elastic/beats#24713).

I was able to switch between 2 different Fleet Servers by adjusting the URL in the Settings flyout.

[hbharding]

Left 2 comments

In addition, I want to confirm that the flyout's button says

and after the user confirm changes through the modal, the flyout's button should use a loading indicator and say

[hbharding]

Found 1 more small thing

[jen-huang]

This is an initial code read review, will come back and do local testing.

I was wondering your thoughts on urls vs hosts, we have used both interchangeably for Kibana url/hosts support. @hbharding maybe you can weigh in on the UX side on rationale of surfacing one vs the other term in the UI. I was thinking hosts might be more consistent with other parts of the stack, such as Kibana's elasticsearch.hosts setting, but I'm not aware of many other examples.

[jen-huang]

Tested locally and the main behavior works as expected, I see fleet.hosts populated in the agent yaml when I change the setting. I am approving but I would like to get consensus on urls vs hosts before this gets merged. It's a little strange that the setting goes from fleet_server.hosts to -> fleet_server_urls and back to -> fleet.hosts in the end.

Small UI suggestion, I think we should add the same non-empty validation for Fleet server & Elasticsearch URL inputs as we currently do for Kibana URLs, currently they don't any show any errors when trying to save with empty values:

[jen-huang]

unlikely that the user will enter the same URL twice, but it might be safer to key on index

[jen-huang]

is it expected to have fleet.hosts be kibana URLs when there there aren't any fleet server urls configured yet? i guess this is temporary until we remove kibana URLs support?

[nchaulet]

Yes that correct agent 7.13 will only support fleet.hosts even for Kibana during a short period to not break all of our CI

[hbharding]

Thanks for raising the inconsistency on host vs url @jen-huang #94364 (review). It wasn't a conscious decision on my part. I think Fleet Server Host as the input label makes sense (as long we provide a description saying this is the URL of the host, which we do) and it is more consistent with the policy's YAML and other examples you've pointed out in our stack. Using the same logic, we would also rename the ES input to say Elasticsearch Host.

👍 I'm pro host and pro consistency. My only hesitation is that technically speaking the input's value is a URL and not just the host/hostname (number 2 in the diagram). But we address that in the input's help text.

cc @mostlyjason for awareness.

[nchaulet]

Small UI suggestion, I think we should add the same non-empty validation for Fleet server & Elasticsearch URL inputs as we currently do for Kibana URLs, currently they don't any show any errors when trying to save with empty values:

I plan to add this as soon as we remove the Kibana URL I added a comment in the code for that.

[nchaulet]

Updated to use hosts instead of URL

[hbharding]

It looks like there is a stray character that should be removed at the end of the URL:

[kibanamachine]

💚 Build Succeeded

• continuous-integration/kibana-ci/pull-request
• Commit: d5fc1c1
• Storybooks Preview

Metrics [docs]

Module Count

Fewer modules leads to a faster build time

id	before	after	diff
fleet	461	462	+1

Async chunks

Total size of all lazy-loaded chunks that will be downloaded as the user navigates the app

id	before	after	diff
fleet	705.7KB	716.3KB	+10.7KB

Saved Objects .kibana field count

Every field in each saved object type adds overhead to Elasticsearch. Kibana needs to keep the total field count below Elasticsearch's default limit of 1000 fields. Only specify field mappings for the fields you wish to search on or query. See https://www.elastic.co/guide/en/kibana/master/development-plugin-saved-objects.html#_mappings

id	before	after	diff
ingest_manager_settings	4	5	+1

History

• 💚 Build #115524 succeeded ae350b8
• 💚 Build #115329 succeeded 2e52470
• 💚 Build #115315 succeeded 193f12850cae61c31783b0b42d9ea6c0f9215915
• 💚 Build #115285 succeeded 4e6979a
• 💚 Build #115168 succeeded 5e04bd9

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

cc @nchaulet

[kibanamachine]

💚 Backport successful

✅ 7.x / #95574

This backport PR will be merged automatically after passing CI.

[amolnater-qasource]

Hi @EricDavisX

We have created 02 testcases for above merged PR. Test-cases link are as follows:

• C76943
• C76944

Further we have updated 13 testcases under Ingest Manager Test suite Section: Fleet Settings. Please let us know if we have missed anything to put down in expected result.

Thanks
QAS

[hbharding]

@nchaulet We got some input from tech writers for some small text changes here #94624