a3793ecac5
* Disabling TLSv1 from being enabled by default * Adding breaking change docs * Update docs/migration/migrate_7_0.asciidoc Co-Authored-By: kobelb <brandon.kobel@gmail.com> * Using the schema defaults * Fixing type definitions * Adjusting logic for no supported protocols * Adding minSize: 1 to the supported protocols
82 lines
4.4 KiB
Plaintext
82 lines
4.4 KiB
Plaintext
[[breaking-changes-7.0]]
|
|
== Breaking changes in 7.0
|
|
++++
|
|
<titleabbrev>7.0</titleabbrev>
|
|
++++
|
|
|
|
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.
|
|
|
|
[float]
|
|
=== Deprecated API `/shorten` has been removed
|
|
*Details:* The `/shorten` API has been deprecated since 6.5, when it was replaced by the `/api/shorten_url` API.
|
|
|
|
*Impact:* The '/shorten' API has been removed. Use the '/api/shorten_url' API instead.
|
|
|
|
[float]
|
|
=== Deprecated kibana.yml setting logging.useUTC has been replaced with logging.timezone
|
|
*Details:* Any timezone can now be specified by canonical id.
|
|
|
|
*Impact:* The logging.useUTC flag will have to be replaced with a timezone id. If set to true the id is `UTC`.
|
|
|
|
[float]
|
|
=== kibana.yml setting `elasticsearch.url` sets port based on protocol
|
|
*Details:* In prior versions of Kibana, if no port was specified in `elasticsearch.url` a default of 9200 was chosen.
|
|
The port is now protocol dependent: https ports will use 443, and http ports will use 80.
|
|
|
|
*Impact:* If your `elasticsearch.url` was dependent on an unspecified port set to 9200, `:9200` will have to be appended to the url.
|
|
|
|
[float]
|
|
=== kibana.yml setting `server.ssl.supportedProtocols` excludes TLSv1 by default
|
|
*Details:* TLSv1 support has been removed by default, it's still possible to opt-in to TLSv1 support by explicitly setting
|
|
`server.ssl.supportedProtocols`
|
|
|
|
*Impact:* Users relying upon TLSv1 will be unable to use Kibana unless `server.ssl.supportedProtocols` is explicitly set.
|