migrate_8_18.asciidoc 6.8 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153
  1. [[migrating-8.18]]
  2. == Migrating to 8.18
  3. ++++
  4. <titleabbrev>8.18</titleabbrev>
  5. ++++
  6. This section discusses the changes that you need to be aware of when migrating
  7. your application to {es} 8.18.
  8. See also <<release-highlights>> and <<es-release-notes>>.
  9. coming::[8.18.0]
  10. [discrete]
  11. [[breaking-changes-8.18]]
  12. === Breaking changes
  13. The following changes in {es} 8.18 might affect your applications
  14. and prevent them from operating normally.
  15. Before upgrading to 8.18, review these changes and take the described steps
  16. to mitigate the impact.
  17. [discrete]
  18. [[breaking_818_analysis_changes]]
  19. ==== Analysis changes
  20. [[change_semantic_text_to_act_like_normal_text_field]]
  21. .Change Semantic Text To Act Like A Normal Text Field
  22. [%collapsible]
  23. ====
  24. *Details* +
  25. The previous semantic_text format used a complex subfield structure in _source to store the embeddings. This complicated interactions/integrations with semantic_text fields and _source in general. This new semantic_text format treats it as a normal text field, where the field's value in _source is the value assigned by the user.
  26. *Impact* +
  27. Users who parsed the subfield structure of the previous semantic_text format in _source will need to update their parsing logic. The new format does not directly expose the chunks and embeddings generated from the input text. The new format will be applied to all new indices, any existing indices will continue to use the previous format.
  28. ====
  29. [discrete]
  30. [[breaking_818_cluster_and_node_setting_changes]]
  31. ==== Cluster and node setting changes
  32. [[drop_tls_rsa_cipher_support_for_jdk_24]]
  33. .Drop `TLS_RSA` cipher support for JDK 24
  34. [%collapsible]
  35. ====
  36. *Details* +
  37. This change removes `TLS_RSA` ciphers from the list of default supported ciphers, for Elasticsearch deployments running on JDK 24.
  38. *Impact* +
  39. The dropped ciphers are `TLS_RSA_WITH_AES_256_GCM_SHA384`, `TLS_RSA_WITH_AES_128_GCM_SHA256`, `TLS_RSA_WITH_AES_256_CBC_SHA256`, `TLS_RSA_WITH_AES_128_CBC_SHA256`, `TLS_RSA_WITH_AES_256_CBC_SHA`, and `TLS_RSA_WITH_AES_128_CBC_SHA`. TLS connections to Elasticsearch using these ciphers will no longer work. Please configure your clients to use one of supported cipher suites.
  40. ====
  41. [discrete]
  42. [[breaking_818_packaging_changes]]
  43. ==== Packaging changes
  44. [[disable_machine_learning_on_macos_x86_64]]
  45. .Disable machine learning on macOS x86_64
  46. [%collapsible]
  47. ====
  48. *Details* +
  49. The machine learning plugin is permanently disabled on macOS x86_64. For the last three years Apple has been selling hardware based on the arm64 architecture, and support will increasingly focus on this architecture in the future. Changes to upstream dependencies of Elastic's machine learning functionality have made it unviable for Elastic to continue to build machine learning on macOS x86_64.
  50. *Impact* +
  51. To continue to use machine learning functionality on macOS please switch to an arm64 machine (Apple silicon). Alternatively, it will still be possible to run Elasticsearch with machine learning enabled in a Docker container on macOS x86_64.
  52. ====
  53. [discrete]
  54. [[breaking_818_rest_api_changes]]
  55. ==== REST API changes
  56. [[set_allow_partial_search_results_true_by_default]]
  57. .Set allow_partial_search_results=true by default
  58. [%collapsible]
  59. ====
  60. *Details* +
  61. Before this change, in case of shard failures, EQL queries always returned an error. With this change, they will keep running and will return partial results.
  62. *Impact* +
  63. EQL queries that would previously fail due to shard failures, will now succeed and return partial results. The previous defaults can be restored by setting `xpack.eql.default_allow_partial_results` cluster setting to `false` or setting with `allow_partial_search_results` to `false` in the query request.
  64. ====
  65. [discrete]
  66. [[breaking_818_esql_changes]]
  67. ==== ES|QL changes
  68. [[limit_scope_skip_unavailable_setting_remote_clusters]]
  69. .Limit the scope of the skip_unavailable setting for remote clusters
  70. [%collapsible]
  71. ====
  72. *Details* +
  73. Before this change, ES|QL would honor the skip_unavailable setting for nonmatching indices errors at planning time, meaning that when a query with a concrete (non-wildcarded) index was issued to a cluster where skip_unavailable=true, the index would be skipped, allowing the query to proceed on any other specified clusters rather than returning an error.
  74. *Impact* +
  75. Remote clusters, regardless of their skip_unavailable setting, will now use the same logic as the local cluster for index expression analysis at plan time. As a result, any missing concrete index in your index expression will return an error rather than partial results.
  76. ====
  77. [discrete]
  78. [[deprecated-8.18]]
  79. === Deprecations
  80. The following functionality has been deprecated in {es} 8.18
  81. and will be removed in a future version.
  82. While this won't have an immediate impact on your applications,
  83. we strongly encourage you to take the described steps to update your code
  84. after upgrading to 8.18.
  85. To find out if you are using any deprecated functionality,
  86. enable <<deprecation-logging, deprecation logging>>.
  87. [discrete]
  88. [[deprecations_818_index_setting]]
  89. ==== Index setting deprecations
  90. [[increase_frozen_indices_deprecation_level_to_critical]]
  91. .Increase the frozen indices deprecation level to `CRITICAL`
  92. [%collapsible]
  93. ====
  94. *Details* +
  95. The migration deprecations API previously returned a warning on frozen indices. Support for reading frozen indices will be removed in 9.0, so in 8.18 this has been made a critical issue.
  96. *Impact* +
  97. Users are required to unfreeze any frozen indices before upgrading to 9.x. (N.B. It was impossible to freeze indices in 8.x, so this only applies to 7.x indices which have not been reindexed.)
  98. ====
  99. [discrete]
  100. [[deprecations_818_rest_api]]
  101. ==== REST API deprecations
  102. [[deprecate_ability_to_connect_to_nodes_of_versions_8_17_earlier]]
  103. .Deprecate ability to connect to nodes of versions 8.17 and earlier
  104. [%collapsible]
  105. ====
  106. *Details* +
  107. Versions 9.0.0 and later of {es} will not support communication with nodes of versions earlier than 8.18.0, so the ability to connect to nodes of earlier versions is deprecated in this version. This applies both to communication within a cluster and communication across clusters (e.g. for <<modules-cross-cluster-search,{ccs}>> or <<xpack-ccr,{ccr}>>).
  108. {es} will report in its <<deprecation-logging, deprecation logging>> each time it opens a connection to a node that will not be supported from version 9.0.0 onwards. You must upgrade all your clusters to version 8.18.0 or later before upgrading any of your clusters to 9.0.0 or later.
  109. *Impact* +
  110. Upgrade all of your clusters to at least 8.18.0 before upgrading any of them to 9.0.0 or later.
  111. ====
  112. [[v_7_deprecation_logging_set_to_critical]]
  113. .V_7 deprecation logging set to critical
  114. [%collapsible]
  115. ====
  116. *Details* +
  117. This changes the V_7 API deprecation logging level to CRITICAL.
  118. *Impact* +
  119. Any usage of deprecated V_7 API features will now be logged at the CRITICAL level. This does not change functionality.
  120. ====