[Fleet] Add a setting inside Agent Policy for FQDN

[jlind23]

FQDN will soon be added to Beats and Elastic Agent as an opt-in option. (By default they will send the same data as before)

The new configuration will be a feature flag as described on elastic/elastic-agent#2185. It'll be:

Feature flag generic config:

agent:
  features:
    feature_1:
      enabled:
      config1:
      config2:
      ...
      configN:
    feature_2:
      enabled:
      config1:
      config2:
      ...
      configN:
    ...
    feature_N:
      enabled:
      config1:
      config2:
      ...
      configN:

Feature flag for FQDN:

agent.features.fqdn.enabled: true|false

Related issues:

• Report FQDN on host.name enabled by a feature flag elastic-agent#2185
• Report host name as FQDN on all platforms beats#1070

[elasticmachine]

Pinging @elastic/fleet (Team:Fleet)

[jlind23]

@dborodyansky @nimarezainia can I please have your eyes on this in order to have a proper design?

[dborodyansky]

Based on discussion, design mockup suggestion below. Rationale for using radio buttons instead of a switch is to show clarity of choice and contextual examples.

A few questions to consider:

• Is "Domain Name Format" an appropriate title?
• What is the default setting? (It should be listed first and selected by default.)
• Is "Hostname" a proper definition of "not FQDN"?
• Are there better examples than what is shown?
• Will we have docs to link to?

[kpollich]

Thanks a ton @dborodyansky - I'll answer your questions below as best I can.

Is "Domain Name Format" an appropriate title?

I think "Host name format" makes more sense.

What is the default setting? (It should be listed first and selected by default.)

Default will be Hostname - this aligns with the current behavior. FQDN is a special case opt-in. So Hostname should be first and selected by default.

Is "Hostname" a proper definition of "not FQDN"?

Yes this seems fine to me. See https://en.wikipedia.org/wiki/Hostname. We use this term because it aligns with the standard command line tool or system naming, e.g.

Are there better examples than what is shown?

Yes, probably. @nimarezainia do you have any examples from customer requests for this functionality that could be shared privately and inform better example values? I do think it'd be good to have the Hostname and FQDN values correlate, e.g.

# Hostname
My-Laptop

# FQDN
My-Laptop.acme.co

Will we have docs to link to?

I think we should. It'd be good to at least get a small paragraph about when someone might want to use each option. For example, in a highly-virtualized setting with many observed Docker containers, FQDN values are likely useless. In the employee laptop use case, though, FQDN is likely helpful to differentiate between many machines with the same or similar hostnames like Admins-Macbook-Pro.

[dborodyansky]

Thank you for the clarification @kpollich. Design updated and below:

[AndersonQ]

hey folks, I updated the issue with the new opt-in config and the related Elastic Agent issue.

[jlind23]

@hop-dev @jen-huang @kpollich Can we add a "beta" disclaimer in the UI as APM and potentially others will not be ready for 8.8 and that the values might differ from a component to another?
cc @joshdover

[hop-dev]

@jlind23 this is easy enough, it would be easier if we knew exactly which integrations don't support it for the tooltip text.

I also think we should add something like the text underlined in green.

[jen-huang]

@hop-dev Let's leave out the tooltip and just have the Beta badge - that is more consistent with how we handle our beta messaging in other parts of the UI.

@nimarezainia, WDYT about calling out the supported agent version? We do have precedent of a similar copy when we deprecated unenrollment timeout, but I'm not sure if that's the right long-term approach:

[hop-dev]

Maybe we should have a doc link as Dmitry originally intended and we can lay out the exact behaviour of the feature once we know? I originally omitted it due to time constraints

I'll add the beta badge for now

[nimarezainia]

@hop-dev I like suggestion from @jen-huang - helps being as descriptive as possible i the product itself. We certainly can point the user to docs for full coverage of the feature. but in cases where we have lack of support (or mish mash of support) it's best to modify the copy and be explicit.