Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Remove kibana.defaultAppId #54088

Closed
flash1293 opened this issue Jan 7, 2020 · 11 comments · Fixed by #109798
Closed

Remove kibana.defaultAppId #54088

flash1293 opened this issue Jan 7, 2020 · 11 comments · Fixed by #109798
Assignees
Labels

Comments

@flash1293
Copy link
Contributor

flash1293 commented Jan 7, 2020

Currently there are two settings around which page to load when the user navigates to a Kibana instance without a path - the defaultRoute advanced setting that allows to load another app than the default kibana app (e.g. app/canvas) and the yml file setting kibana.defaultAppId that's used to route to a sub app within the kibana app.

On the one hand this is inherently confusing because two different things are described as "app" (without much details in the documentation) and on the other hand the kibana app will be broken into multiple apps in the next major version, making the extra setting unnecessary.

While maintaining BWC is possible IMHO it is too complicated in this case to justify the effort, so I propose a breaking change in 8.0.

kibana.defaultAppId should be removed completely and all places currently referencing defaultAppId should be changed to the defaultRoute ui setting. This change has to be documented in the breaking change log.

Which release will ship the breaking change?

8.0

Describe the change. How will it manifest to users?

If the user has set a kibana.defaultAppId key in their kibana.yml, Kibana will refuse to start up.

How many users will be affected?

We don't have telemetry on this, but this setting has been superseded a long time, so impact should be minimal. There's already a warning in the logs in recent Kibana versions if it is used.

What can users do to address the change manually?

Users should remove the kibana.defaultAppId setting and replace it using an advanced setting "defaultRoute"

How could we make migration easier with the Upgrade Assistant?

Theoretically we could show a warning in the assistant if the setting is present by exposing it to the browser and pass it to the assistant plugin, but I'm not sure whether it's worth it. The Elasticsearch UI team might now better.

Are there any edge cases?

Test Data

Set kibana.defaultAppId to discover. This works in current version of Kibana, but will break in 8.0

Related #46331

@flash1293 flash1293 added Team:Visualizations Visualization editors, elastic-charts and infrastructure Feature:NP Migration labels Jan 7, 2020
@elasticmachine
Copy link
Contributor

Pinging @elastic/kibana-app (Team:KibanaApp)

@flash1293
Copy link
Contributor Author

@elastic/kibana-platform is the plan proposed here sound? I'm not sure whether I'm missing an aspect.

@joshdover
Copy link
Contributor

Sounds reasonable to me, but I also don't have a lot of context on this. If I remember correctly, I think @legrego was actually the last one to touch this feature.

@legrego
Copy link
Member

legrego commented May 28, 2020

Yes, let's please drop defaultAppId for 8.0. Folks should be using the defaultRoute UI setting now, as this is space aware and more flexible. We should deprecate this as soon as possible so that we're at least warning users in the logs when we first start up if they have this customized.

@cjcenizal
Copy link
Contributor

@flash1293 #6902 looks very similar to this issue. It contains some historical context which might not be relevant any more. Should we close it in favor of this one?

@flash1293
Copy link
Contributor Author

Closed the other issue, thanks @cjcenizal

@flash1293 flash1293 added Feature:Upgrade Assistant Team:Kibana Management Dev Tools, Index Management, Upgrade Assistant, ILM, Ingest Node Pipelines, and more labels Oct 27, 2020
@elasticmachine
Copy link
Contributor

Pinging @elastic/es-ui (Team:Elasticsearch UI)

@kobelb kobelb added NeededFor:KibanaApp and removed Team:Visualizations Visualization editors, elastic-charts and infrastructure labels Oct 28, 2020
@alisonelizabeth
Copy link
Contributor

I'm going to remove the Elasticsearch UI team label. This deprecation should be registered by the plugin owner via the core deprecations service (#94845). All registered deprecations will be displayed in the Upgrade Assistant (to be implemented via #97159). Feel free to reach out to myself or the core team with any questions!

@alisonelizabeth alisonelizabeth added Team:Visualizations Visualization editors, elastic-charts and infrastructure and removed Team:Kibana Management Dev Tools, Index Management, Upgrade Assistant, ILM, Ingest Node Pipelines, and more labels Apr 19, 2021
@stratoula
Copy link
Contributor

stratoula commented Aug 20, 2021

There are two tasks here:

  1. ✔️ Add the deprecation on the upgrade assistant in 7.16. Here is an example of how we did it for timelion app https://github.com/elastic/kibana/pull/94845/files?file-filters%5B%5D=.js&file-filters%5B%5D=.json&file-filters%5B%5D=.md&file-filters%5B%5D=.ts&file-filters%5B%5D=.tsx&owned-by%5B%5D=stratoula
    We need to involve the docs-team for the copies

  2. Remove the setting in v8.0

@stratoula
Copy link
Contributor

stratoula commented Aug 20, 2021

As @lukeelmers informed me we might not need to do the first step. It seems that all the deprecated settings are already surfaced in the upgrade assistant

#54088 (comment)

We need to check it first!

Update: I tested it. It is already there :)

image

@timroes timroes assigned timroes and unassigned flash1293 Aug 24, 2021
@stratoula
Copy link
Contributor

I think we can also close these issues (after the PR is merged)

cc @timroes

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

9 participants