[Discuss] Public URLs in Kibana and Cloud

[alisonelizabeth]

In serverless, there are several instances where cloud UI will need to link to Kibana and vice versa.

We need to find a way to document or enforce the public URLs that cloud is putting in their interface. For example, create a constants file of routes that we should support in cloud and create integration tests to verify they are available.

in Cloud

Kibana page	URL
Management	/app/management
Data retention	TBD - not implemented yet

in Kibana

Cloud page	URL
Users and roles	-
Performance	-
Billing and subscription	-

[elasticmachine]

Pinging @elastic/platform-deployment-management (Team:Deployment Management)

[alisonelizabeth]

cc @clintandrewhall @zinckiwi

[clintandrewhall]

@lukeelmers if you have any ideas on a “universal” way of maintaining this.

[lukeelmers]

When it comes to Cloud talking to Kibana:

We really shouldn't be making breaking changes to these URLs in the first place without adding redirects, so IMO adding some integration tests in Kibana to verify the routes work is the simplest path forward. That way self-managed Kibana would benefit from the additional test coverage as well. These test would be owned by whichever team owns the applications that register the routes cloud needs.

It might also help on the Cloud UI side to have these consts consolidated into a single file that the deployment management team could be codeowners for, to ensure that someone in AppEx is always aware if any changes are ever made to these.

[jloleysens]

Iterating on what Luke said:

Kibana has a redirect app that uses locators (the most formalised version of deep-linking we have). This app lives at:

/app/r?l=<locator_id>&v=<version>&p=<params>

See src/plugins/share/public/url_service/redirect/redirect_manager.ts.

Locators are more work than "just linking", but they provide a few things:

• migration of persistable state built in -- so they are robust to data changes over time
• are an abstraction over hard-cording Kibana paths
• richer integration with all the "capabilities" of a page in that state can also be passed in via the params contract
• easily share linkable locations across Kibana plugins

With locators we could:

• (optional) create a new package containing relevant locator params (id, version and type def of params)
• create a React component, in Kibana, that renders something like <div data-test-subj="kibana-deep-link-target" />
• render the component on all relevant paths
• write an e2e test that loops over the locators, checking for tag as smoke-test success indicator
• (optional) publish/share the package

In this case, it would be up to Cloud to provide us a way to link back.