2018-09-27 11:41:38 -04:00
|
|
|
[float]
|
2018-01-03 06:16:42 -05:00
|
|
|
[[breaking_70_settings_changes]]
|
|
|
|
=== Settings changes
|
|
|
|
|
2018-09-27 11:41:38 -04:00
|
|
|
[float]
|
2018-09-19 15:21:29 -04:00
|
|
|
==== The default for `node.name` is now the hostname
|
|
|
|
|
|
|
|
`node.name` now defaults to the hostname at the time when Elasticsearch
|
|
|
|
is started. Previously the default node name was the first eight characters
|
|
|
|
of the node id. It can still be configured explicitly in `elasticsearch.yml`.
|
|
|
|
|
2018-09-27 11:41:38 -04:00
|
|
|
[float]
|
2018-01-03 06:16:42 -05:00
|
|
|
==== Percolator
|
|
|
|
|
|
|
|
* The deprecated `index.percolator.map_unmapped_fields_as_string` setting has been removed in favour of
|
2018-04-18 09:18:08 -04:00
|
|
|
the `index.percolator.map_unmapped_fields_as_text` setting.
|
|
|
|
|
2018-09-27 11:41:38 -04:00
|
|
|
[float]
|
2018-04-18 09:18:08 -04:00
|
|
|
==== Index thread pool
|
|
|
|
|
|
|
|
* Internally, single-document index/delete/update requests are executed as bulk
|
|
|
|
requests with a single-document payload. This means that these requests are
|
|
|
|
executed on the bulk thread pool. As such, the indexing thread pool is no
|
|
|
|
longer needed and has been removed. As such, the settings
|
2018-04-19 16:59:58 -04:00
|
|
|
`thread_pool.index.size` and `thread_pool.index.queue_size` have been removed.
|
|
|
|
|
2018-09-27 11:41:38 -04:00
|
|
|
[float]
|
2018-04-19 16:59:58 -04:00
|
|
|
[[write-thread-pool-fallback]]
|
|
|
|
==== Write thread pool fallback
|
|
|
|
|
|
|
|
* The bulk thread pool was replaced by the write thread pool in 6.3.0. However,
|
|
|
|
for backwards compatibility reasons the name `bulk` was still usable as fallback
|
|
|
|
settings `thread_pool.bulk.size` and `thread_pool.bulk.queue_size` for
|
|
|
|
`thread_pool.write.size` and `thread_pool.write.queue_size`, respectively, and
|
|
|
|
the system property `es.thread_pool.write.use_bulk_as_display_name` was
|
|
|
|
available to keep the display output in APIs as `bulk` instead of `write`.
|
|
|
|
These fallback settings and this system property have been removed.
|
2018-05-02 14:42:05 -04:00
|
|
|
|
2018-09-27 11:41:38 -04:00
|
|
|
[float]
|
2018-05-02 14:42:05 -04:00
|
|
|
[[remove-http-enabled]]
|
|
|
|
==== Http enabled setting removed
|
|
|
|
|
2018-05-22 11:29:31 -04:00
|
|
|
* The setting `http.enabled` previously allowed disabling binding to HTTP, only allowing
|
2018-05-02 14:42:05 -04:00
|
|
|
use of the transport client. This setting has been removed, as the transport client
|
|
|
|
will be removed in the future, thus requiring HTTP to always be enabled.
|
2018-05-22 11:29:31 -04:00
|
|
|
|
2018-09-27 11:41:38 -04:00
|
|
|
[float]
|
2018-05-22 11:29:31 -04:00
|
|
|
[[remove-http-pipelining-setting]]
|
|
|
|
==== Http pipelining setting removed
|
|
|
|
|
|
|
|
* The setting `http.pipelining` previously allowed disabling HTTP pipelining support.
|
|
|
|
This setting has been removed, as disabling http pipelining support on the server
|
|
|
|
provided little value. The setting `http.pipelining.max_events` can still be used to
|
|
|
|
limit the number of pipelined requests in-flight.
|
2018-09-12 13:37:11 -04:00
|
|
|
|
2018-09-27 11:41:38 -04:00
|
|
|
[float]
|
2018-09-12 13:37:11 -04:00
|
|
|
==== Cross-cluster search settings renamed
|
|
|
|
|
|
|
|
The cross-cluster search remote cluster connection infrastructure is also used
|
|
|
|
in cross-cluster replication. This means that the setting names
|
|
|
|
`search.remote.*` used for configuring cross-cluster search belie the fact that
|
|
|
|
they also apply to other situations where a connection to a remote cluster as
|
|
|
|
used. Therefore, these settings have been renamed from `search.remote.*` to
|
|
|
|
`cluster.remote.*`. For backwards compatibility purposes, we will fallback to
|
|
|
|
`search.remote.*` if `cluster.remote.*` is not set. For any such settings stored
|
|
|
|
in the cluster state, or set on dynamic settings updates, we will automatically
|
|
|
|
upgrade the setting from `search.remote.*` to `cluster.remote.*`. The fallback
|
|
|
|
settings will be removed in 8.0.0.
|
2018-11-05 22:56:50 -05:00
|
|
|
|
2018-11-06 00:59:11 -05:00
|
|
|
[float]
|
2018-11-05 22:56:50 -05:00
|
|
|
[[include-realm-type-in-setting]]
|
|
|
|
==== Security realms settings
|
|
|
|
|
|
|
|
The settings for all security realms must now include the realm type as part
|
|
|
|
of the setting name, and the explicit `type` setting has been removed.
|
|
|
|
|
|
|
|
A realm that was previous configured as:
|
|
|
|
[source,yaml]
|
|
|
|
--------------------------------------------------
|
|
|
|
xpack.security.authc.realms:
|
|
|
|
ldap1:
|
|
|
|
type: ldap
|
|
|
|
order: 1
|
|
|
|
url: "ldaps://ldap.example.com/"
|
|
|
|
--------------------------------------------------
|
|
|
|
|
|
|
|
Must be migrated to:
|
|
|
|
[source,yaml]
|
|
|
|
--------------------------------------------------
|
|
|
|
xpack.security.authc.realms:
|
|
|
|
ldap.ldap1:
|
|
|
|
order: 1
|
|
|
|
url: "ldaps://ldap.example.com/"
|
|
|
|
--------------------------------------------------
|
|
|
|
|
|
|
|
Any realm specific secure settings that have been stored in the elasticsearch
|
|
|
|
keystore (such as ldap bind passwords, or passwords for ssl keys) must be updated
|
|
|
|
in a similar way.
|