honeymoose
/
OpenSearch
mirror of https://github.com/honeymoose/OpenSearch.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity
OpenSearch/docs/reference/migration/migrate_7_0/settings.asciidoc

62 lines
2.9 KiB
Plaintext
Raw Normal View History

percolator: remove deprecated map_unmapped_fields_as_string setting
2018-01-03 06:16:42 -05:00
[[breaking_70_settings_changes]]
=== Settings changes
Core: Default node.name to the hostname (#33677) Changes the default of the `node.name` setting to the hostname of the machine on which Elasticsearch is running. Previously it was the first 8 characters of the node id. This had the advantage of producing a unique name even when the node name isn't configured but the disadvantage of being unrecognizable and not being available until fairly late in the startup process. Of particular interest is that it isn't available until after logging is configured. This forces us to use a volatile read whenever we add the node name to the log. Using the hostname is available immediately on startup and is generally recognizable but has the disadvantage of not being unique when run on machines that don't set their hostname or when multiple elasticsearch processes are run on the same host. I believe that, taken together, it is better to default to the hostname. 1. Running multiple copies of Elasticsearch on the same node is a fairly advanced feature. We do it all the as part of the elasticsearch build for testing but we make sure to set the node name then. 2. That the node.name defaults to some flavor of "localhost" on an unconfigured box feels like it isn't going to come up too much in production. I expect most production deployments to at least set the hostname. As a bonus, production deployments need no longer set the node name in most cases. At least in my experience most folks set it to the hostname anyway.
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`.
percolator: remove deprecated map_unmapped_fields_as_string setting
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
Remove the index thread pool (#29556) Now that single-document indexing requests are executed on the bulk thread pool the index thread pool is no longer needed. This commit removes this thread pool from Elasticsearch.
2018-04-18 09:18:08 -04:00
the `index.percolator.map_unmapped_fields_as_text` setting.
==== 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
Remove bulk fallback for write thread pool (#29609) The name of the bulk thread pool was renamed to "write" with "bulk" as a fallback name. This change was made in 6.x for BWC reasons yet in 7.0.0 we are removing this fallback. This commit removes this fallback for the write thread pool.
2018-04-19 16:59:58 -04:00
`thread_pool.index.size` and `thread_pool.index.queue_size` have been removed.
[[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.
Network: Remove http.enabled setting (#29601) This commit removes the http.enabled setting. While all real nodes (started with bin/elasticsearch) will always have an http binding, there are many tests that rely on the quickness of not actually needing to bind to 2 ports. For this case, the MockHttpTransport.TestPlugin provides a dummy http transport implementation which is used by default in ESIntegTestCase. closes #12792
2018-05-02 14:42:05 -04:00
[[remove-http-enabled]]
==== Http enabled setting removed
Make http pipelining support mandatory (#30695) This is related to #29500 and #28898. This commit removes the abilitiy to disable http pipelining. After this commit, any elasticsearch node will support pipelined requests from a client. Additionally, it extracts some of the http pipelining work to the server module. This extracted work is used to implement pipelining for the nio plugin.
2018-05-22 11:29:31 -04:00
* The setting `http.enabled` previously allowed disabling binding to HTTP, only allowing
Network: Remove http.enabled setting (#29601) This commit removes the http.enabled setting. While all real nodes (started with bin/elasticsearch) will always have an http binding, there are many tests that rely on the quickness of not actually needing to bind to 2 ports. For this case, the MockHttpTransport.TestPlugin provides a dummy http transport implementation which is used by default in ESIntegTestCase. closes #12792
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.
Make http pipelining support mandatory (#30695) This is related to #29500 and #28898. This commit removes the abilitiy to disable http pipelining. After this commit, any elasticsearch node will support pipelined requests from a client. Additionally, it extracts some of the http pipelining work to the server module. This extracted work is used to implement pipelining for the nio plugin.
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.
Add migration note for remote cluster settings (#33632) The remote cluster settings search.remote.* have been renamed to cluster.remote.* and are automatically upgraded in the cluster state on gateway recovery, and on put. This commit adds a note to the migration docs for these changes.
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.