[Fleet] Add deployment details call out to integrations browse view

[alexfrancoeur]

For the developer experience, it is important to have key information to push data to Elasticsearch if you're not using an Elastic data shipper like agent. This is particularly helpful for language clients. As a first step to improve this experience, we plan to add a "deployment details" call out in the top of the page to simplify the back and forth between products, config files and applications.

This user experience will have three key bit of information

• The Elasticsearch endpoint and a quick copy button (Cloud & Self-Managed)
• The Cloud ID and a quick copy button (Cloud only, lives in the cloud plugin already)
• A link to the API key management page (/app/management/security/api_keys) and supporting documentation (link)

@dborodyansky After speaking with the clients team, we agree that referencing API key management would be a useful CTA in this popup. Could you think through what this UX might look like? We'll also need to work with @gchaps and the team to make sure this pop up has the appropriate context and matches language in cloud and self managed environments. Happy to help with the details here.

While not a primary objective for this work, it may be worth considering building this component to be reusable. I could see the benefit in including this in the API management UI as well.

cc: @philkra @sethpayne @technige @thomasneirynck @clintandrewhall @joshdover @snide @mostlyjason @mriley @linyaru @thesmallestduck

[elasticmachine]

Pinging @elastic/fleet (Team:Fleet)

[dborodyansky]

@alexfrancoeur, Does the following design iteration align to our goal?

[alexfrancoeur]

I can't seem to resize the popover, but this is what I was thinking. Not committed to the text changes, was just looking to make room on the top 😄

Basically, just looking to add some more context around those two buttons. But otherwise, I think the design is good. My only concern with the primary button is that it draws a lot of attention and looks like the only meaningful action on this popover. Is there a way we can make it more subtle?

[snide]

Designs look good. Only comment might be to make the text for the button a little more clear. "View deployment and Elasticsearch details"? I'm just worried folks won't know what deployment means in this context. @gchaps might have some suggestions.

[dborodyansky]

Design updated.

@KOTungseth, thank you for helping us with Unified Integrations copy so far. Would you mind taking a look at this button and popover as well, and letting us know your thoughts?

[joshdover]

@alexfrancoeur I suspect that for Self-Managed we don't have any Elasticsearch URL to display here that we can definitely say will be publicly available, nor can we even really safely expose to the browser (cc @elastic/kibana-security can check me on this). Reason being that admins may not want the elasticsearch.hosts config to be viewable to end-users for security reasons. This is likely the same reason we don't show the URL for Self-Managed clusters in the Beats tutorials today.

If my suspicions are correct, some ideas for how to handle Self-Managed:

• Hide this UI completely for Self-Managed + ensure the Clients doc updates that reference this UI clearly explain that this is only available on Cloud
• Have a fallback UI that explains how to find the endpoint
  • Not sure where we'd actually direct users to find this though. I would say the kibana.yml but that isn't how all deployments are configured (eg. Docker env variables) and we don't currently have a way to know where the config came from.
• Add a new config key like elasticsearch.publicEndpoint for admins who want their users to be able to see this UI
  • This could be broadly useful for other features in the future, but I don't think we could make it a required config and I'm not sure how we could make this config discoverable to admins.

[jportner]

@alexfrancoeur I suspect that for Self-Managed we don't have any Elasticsearch URL to display here that we can definitely say will be publicly available, nor can we even really safely expose to the browser (cc @elastic/kibana-security can check me on this). Reason being that admins may not want the elasticsearch.hosts config to be viewable to end-users for security reasons.

Agreed.

[snide]

I think as a first step it's perfectly OK to hide the UI. Anyone self-managed should be vocalized the endpoint or setting it up themselves. I think it's fine to go with @joshdover's first suggestion here.

[alexfrancoeur]

Agreed. Given the time constraints, I'd be OK with hiding this experience in self-managed environments. I do have one question. Is there enough value in linking out to the API key management UI? If so, we could surface this CTA but would likely need to generalize the entry point description. "View Elasticsearch deployment details" to something else.

[joshdover]

Agreed.

Great 👍

Is there enough value in linking out to the API key management UI?

my 2c: it might be confusing. It's already a bit of a disjointed experience here where we show this UI in this app without any direct connection to language clients. That said, showing the deployment details makes sense in the context of many integrations, not just language clients, whereas API keys may be less obvious since they're not referenced in our Beats docs, etc. but Elasticsearch info is.

[alexfrancoeur]

my 2c: it might be confusing.

Yeah, I was feeling that way as well.