Migrating to 7.14

Details
If a failure occurs during a rolling upgrade then Elasticsearch may prematurely conclude that the upgrade is complete and enable functionality which is incompatible with earlier versions. In versions before 7.14 Elasticsearch would accept older nodes into the cluster after completing the upgrade despite having enabled incompatible functionality, as long as the older nodes were from the same major series. From 7.14 onwards Elasticsearch will not accept any older nodes into a fully-upgraded cluster.

Impact
If a failure occurs during a rolling upgrade and older nodes cannot rejoin the cluster then you must upgrade the affected nodes. Once upgraded, they will join the cluster again.

Details
Configuring any SSL settings for xpack.security.transport.ssl without also configuring xpack.security.transport.ssl.enabled generates warnings in the deprecation log. In 8.0, this configuration will result in errors.

Impact
To avoid deprecation warnings, either:

If you want to enable SSL, follow the instructions to encrypt internode communications with TLS. As part of this configuration, explicitly set xpack.security.transport.ssl.enabled as true.

For example:

xpack.security.transport.ssl.enabled: true 
xpack.security.transport.ssl.keystore.path: elastic-certificates.p12
xpack.security.transport.ssl.truststore.path: elastic-certificates.p12

Details
Configuring any SSL settings for xpack.security.http.ssl without also configuring xpack.security.http.ssl.enabled generates warnings in the deprecation log. In 8.0, this configuration will result in errors.

Impact
To avoid deprecation warnings, either:

If you want to enable SSL, follow the instructions to encrypt HTTP client communications for Elasticsearch. As part of this configuration, explicitly set xpack.security.http.ssl.enabled as true.

For example:

xpack.security.http.ssl.enabled: true 
xpack.security.http.ssl.certificate: elasticsearch.crt
xpack.security.http.ssl.key: elasticsearch.key
xpack.security.http.ssl.certificate_authorities: [ "corporate-ca.crt" ]

Details
Enabling SSL for the transport interface without also configuring a certificate and key through use of the xpack.security.transport.ssl.keystore.path setting or the xpack.security.transport.ssl.certificate and xpack.security.transport.ssl.key settings generates warnings in the deprecation log. In 8.0, this configuration will result in errors.

Impact
If xpack.security.transport.ssl.enabled is set to true, provide a certificate and key using the xpack.security.transport.ssl.keystore.path setting or the xpack.security.transport.ssl.certificate and xpack.security.transport.ssl.key settings. If a certificate and key is not provided, Elasticsearch will generate warnings in the deprecation log.

Details
Enabling SSL for the HTTP layer without also configuring a certificate and key through use of the xpack.security.http.ssl.keystore.path setting or the xpack.security.http.ssl.certificate and xpack.security.http.ssl.key settings generates warnings in the deprecation log. In 8.0, this configuration will result in errors. Impact
If xpack.security.http.ssl.enabled is set to true, provide a certificate and key using the xpack.security.http.ssl.keystore.path setting or the xpack.security.http.ssl.certificate and xpack.security.http.ssl.key settings. If a certificate and key is not provided, Elasticsearch will generate warnings in the deprecation log.

Details
Currently, remote system indices matching an auto-follow pattern are configured as a follower index automatically, this behavior is deprecated.

Impact
In 8.0.0, remote system indices matching an auto-follow pattern won’t be configured as a follower index automatically. In order to adapt to this new behaviour it is advised to exclude patterns matching system indices such as .tasks and kibana-*.

Details
The setting cluster.routing.allocation.disk.watermark.enable_for_single_data_node should never be explicitly set to false. In 8.0, the only legal value will be true. In a future release, the setting will be removed completely, with same behavior as if the setting was true.

Impact

If your cluster has a single data node then set cluster.routing.allocation.disk.watermark.enable_for_single_data_node: true to opt in to the future behaviour today. If you wish to disable the disk watermarks then set cluster.routing.allocation.disk.threshold_enabled: false.

If your cluster has multiple data nodes then the cluster.routing.allocation.disk.watermark.enable_for_single_data_node setting has no effect and you should discontinue its use.

Details
The geo_bounding_box query’s type parameter has been deprecated in 7.14.0. This parameter is a no-op and has no effect on the query.

Impact
Discontinue use of the type parameter in geo_bounding_box queries.

Details
Elasticsearch security features are disabled by default when operating on a basic or trial license if xpack.security.enabled is not set to true. In Elasticsearch 8.0.0, security features will be enabled by default for all licenses unless you explicitly disable security by setting xpack.security.enabled to false (not recommended).

Before migrating to Elasticsearch 8.0.0, you must explicitly set a value for xpack.security.enabled or Elasticsearch will fail to start. If you have already enabled security features by explicitly setting xpack.security.enabled to true, your configuration will be respected in 8.0.0.

Otherwise, on every node in your cluster, enable Elasticsearch security features by setting xpack.security.enabled to true in elasticsearch.yml. You then configure security for the transport layer on each node, which requires generating a certificate authority (if you don’t have one), creating node security certificates, and configuring internode communication. Refer to set up basic security for the Elastic Stack for steps on configuring security.

Details
Elasticsearch creates "synthetic" realm names on the fly for services like API keys. These synthetic realm names are prefixed with an underscore. Currently, user configured realms can also be given a name with a leading underscore. This creates confusion since realm names are meant to be unique for a node.

Impact
Configuring a realm name with a leading underscore is deprecated. In a future release of Elasticsearch it will result in an error on startup if any user configured realm has a name with a leading underscore.