-
Notifications
You must be signed in to change notification settings - Fork 8.2k
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
Comments
Pinging @elastic/kibana-app (Team:KibanaApp) |
@elastic/kibana-platform is the plan proposed here sound? I'm not sure whether I'm missing an aspect. |
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. |
Yes, let's please drop |
@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? |
Closed the other issue, thanks @cjcenizal |
Pinging @elastic/es-ui (Team:Elasticsearch UI) |
I'm going to remove the |
There are two tasks here:
|
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 We need to check it first! Update: I tested it. It is already there :) |
I think we can also close these issues (after the PR is merged)
cc @timroes |
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 defaultkibana
app (e.g.app/canvas
) and the yml file settingkibana.defaultAppId
that's used to route to a sub app within thekibana
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 referencingdefaultAppId
should be changed to thedefaultRoute
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 theirkibana.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
todiscover
. This works in current version of Kibana, but will break in 8.0Related #46331
The text was updated successfully, but these errors were encountered: