30d4e70507
This is a breaking change that removes the `xpack.monitoring.node_resolver` setting. This setting was deprecated in 5.6, and in 6.1 the setting was limited to `uuid` explicitly. Beginning in 7.0, after this is merged, the setting will no longer exist.
52 lines
No EOL
3.1 KiB
Text
52 lines
No EOL
3.1 KiB
Text
[[breaking-changes-7.0]]
|
|
== Breaking changes in 7.0
|
|
|
|
This section discusses the changes that you need to be aware of when migrating
|
|
your application to Kibana 7.0.
|
|
|
|
See also <<release-highlights>> and <<release-notes>>.
|
|
|
|
[float]
|
|
=== Removed support for tribe nodes
|
|
*Details:* Elasticsearch 7.0 removes the tribe node feature, so Kibana removes it as well.
|
|
|
|
*Impact:* You must remove any tribe node configurations in Kibana. Consider using <<management-cross-cluster-search>> instead, which does not require kibana.yml configurations in Kibana.
|
|
|
|
|
|
[float]
|
|
=== Removed support for running Kibana with a global Node.js installation
|
|
*Details:* Previous versions of Kibana would fallback to using a global installation of Node.js if the distribution included with Kibana was not found.
|
|
Kibana 7.0 will only use the Node.js distribution included in the package.
|
|
|
|
*Impact:* There is no expected impact unless Kibana is installed in a non-standard way.
|
|
|
|
[float]
|
|
=== Advanced setting query:queryString:options no longer applies to filters
|
|
*Details:* In previous versions of Kibana the Advanced Setting `query:queryString:options` was applied to both queries
|
|
and custom filters using the `query_string` query. This could cause errors if a custom filter used options that
|
|
conflicted with the Advanced Setting. In 7.0 `query:queryString:options` will no longer be applied to filters so that
|
|
users can have full control over their custom filters.
|
|
|
|
*Impact:* You must ensure that any saved searches with a `query_string` filter aren't relying implicitly on
|
|
`query:queryString:options`.
|
|
|
|
[float]
|
|
=== Advanced setting query:queryString:options no longer applies `default_field: *` by default.
|
|
*Details:* Elasticsearch removed the ability to create indices with an _all field in 6.0. As a result, a user could end
|
|
up with a mix of indices with and without _all fields if they upgraded from an older version of ES. This could lead to
|
|
inconsistent highlighting in Discover. To work around this issue we added `default_field: *` to query:queryString:options
|
|
to force consistent querying across indices with and without _all. In 7.0 the _all field will be gone from all indices
|
|
so we no longer need this workaround.
|
|
|
|
*Impact:* Since we'll no longer send the `default_field` parameter in Kibana's query_string query, Elasticsearch
|
|
will use the index setting instead. The default for the index setting is also `*`, so most users should not be impacted.
|
|
If some of your indices have a non-default `default_field` setting, you may want to update it or re-add the parameter
|
|
to Kibana's advanced setting.
|
|
|
|
[float]
|
|
=== Deprecated kibana.yml setting `xpack.monitoring.node_resolver` has been removed
|
|
*Details:* This setting has been deprecated since 5.6, when it was explicitly recommended to use `uuid` as its value.
|
|
|
|
*Impact:* This setting is no longer necessary. If you enable {monitoring} across the Elastic Stack, a monitoring agent runs
|
|
on each Elasticsearch node, Logstash node, Kibana instance, and Beat to collect and index metrics. Each node and instance is
|
|
considered unique based on its persistent UUID, which is written to the path.data directory when the node or instance starts. |