2017-11-22 19:49:37 +01:00
[[breaking-changes-7.0]]
== Breaking changes in 7.0
2018-09-12 18:19:38 +02:00
++++
<titleabbrev>7.0</titleabbrev>
++++
2017-11-22 19:49:37 +01:00
This section discusses the changes that you need to be aware of when migrating
your application to Kibana 7.0.
2018-07-27 23:42:21 +02:00
See also <<release-highlights>> and <<release-notes>>.
2017-11-22 19:49:37 +01:00
2019-01-22 21:08:45 +01:00
[float]
=== Removed support for users relying on direct index privileges to the Kibana index in Elasticsearch
*Details:* With the introduction of Kibana RBAC in 6.4, users no longer require privileges to the Kibana index in Elasticsearch. Instead, users
should be granted <<kibana-privileges>>. Prior to 7.0, when a user that relies upon direct index privileges logs into Kibana, a deprecation warning is logged. If you are using the `kibana_user` or `kibana_dashboard_only_user` role to grant access to Kibana, or a custom role using <<kibana-privileges>>, no changes are required.
*Impact:* You must change any roles which grant access to Kibana using index privileges to instead use <<kibana-privileges>>. Watcher jobs using the Reporting attachment type must be updated as well.
2018-01-30 20:36:38 +01:00
[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.
2017-11-22 19:49:37 +01:00
[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.
2019-01-03 22:35:15 +01:00
[float]
=== Removed support for using PhantomJS browser for screenshots in Reporting
*Details:* Since the first release of Kibana Reporting, PhantomJS was used as
the headless browser to capture screenshots of Kibana dashboards and
visualizations. In that short time, Chromium has started offering a new
headless browser library and the PhantomJS maintainers abandoned their project.
We started planning for a transition in 6.5.0, when we made Chromium the
default option, but allowed users to continue using Phantom with the
`xpack.reporting.capture.browser.type: phantom` setting. In 7.0, that setting
will still exist for compatibility, but the only valid option will be
`chromium`.
*Impact:* Before upgrading to 7.0, if you have `xpack.reporting.capture.browser.type`
set in kibana.yml, make sure it is set to `chromium`.
[NOTE]
============
Reporting 7.0 uses a version of the Chromium headless browser that RHEL 6,
CentOS 6.x, and other old versions of Linux derived from RHEL 6. This change
effectively removes RHEL 6 OS server support from Kibana Reporting. Users with
RHEL 6 must upgrade to RHEL 7 to use Kibana Reporting starting with version
7.0.0 of the Elastic stack.
============
2018-03-29 19:57:16 +02:00
[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
2018-07-27 23:42:21 +02:00
and custom filters using the `query_string` query. This could cause errors if a custom filter used options that
2018-03-29 19:57:16 +02:00
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.
2018-07-27 23:42:21 +02:00
*Impact:* You must ensure that any saved searches with a `query_string` filter aren't relying implicitly on
2018-05-10 23:37:00 +02:00
`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
2018-07-27 23:42:21 +02:00
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
2018-08-13 15:27:20 +02:00
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.
2018-09-04 23:52:51 +02:00
2018-09-05 00:09:16 +02:00
[float]
2018-09-04 23:52:51 +02:00
=== 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`.
2018-09-17 16:54:05 +02:00
[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.
2018-12-18 21:38:26 +01:00
[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.
2019-01-14 21:37:58 +01:00
[float]
=== kibana.yml setting `server.ssl.cert` is no longer valid
*Details:* This deprecated setting has been removed and `server.ssl.certificate` should be used instead.
*Impact:* Users with `server.ssl.cert` set should use `server.ssl.certificate` instead
[float]
=== kibana.yml `server.ssl.enabled` must be set to `true` to enable SSL
*Details:* Previously, if `server.ssl.certificate` and `server.ssl.key` were set, SSL would automatically be enabled.
It's now required that the user sets `server.ssl.enabled` to true for this to occur.
*Impact:* Users with both `server.ssl.certificate` and `server.ssl.key` set must now also set `server.ssl.enabled` to enable SSL.