Bump version to v7.14.0

.ci/bwcVersions

@@ -80,3 +80,4 @@ BWC_VERSION:
   - "7.11.2"
   - "7.12.0"
   - "7.12.1"
+  - "7.13.0"

buildSrc/version.properties

@@ -1,4 +1,4 @@
-elasticsearch     = 7.13.0
+elasticsearch     = 7.14.0
 lucene            = 8.8.2
 
 bundled_jdk_vendor = adoptopenjdk

docs/changelog/27600.yaml

@@ -0,0 +1,8 @@
+pr: 27600
+issues:
+  - 27583
+area: Infra/Settings
+type: enhancement
+summary: Remove setting `index.optimize_auto_generated_id`
+versions:
+  - v8.0.0

docs/changelog/33511.yaml

@@ -0,0 +1,51 @@
+pr: 33511
+issues: []
+area: Search
+type: breaking, enhancement
+summary: Make Fuzziness reject illegal values earlier
+versions:
+  - v8.0.0
+breaking:
+  notable: false
+  title: Make Fuzziness reject illegal values earlier
+  anchor: make_fuzziness_reject_illegal_values_earlier
+  body: >-
+    The current java implementation of Fuzziness leaves a lot of room for
+
+    initializing it with illegal values that either cause errors later when the
+
+    queries reach the shards where they are executed or values that are silently
+
+    ignored in favour of defaults. We should instead tighten the java implementation
+
+    of the class so that we only accept supported values. Currently those are
+
+    numeric values representing the edit distances 0, 1 and 2, optionally also as
+
+    float or string, and the "AUTO" fuzziness, which can come in a cusomizable
+
+    variant that allows specifying two value that define the positions in a term
+
+    where the AUTO option increases the allowed edit distance.
+
+    This change removes several redundant ways of object construction and adds input
+
+    validation to the remaining ones. Java users should either use one of the
+
+    predefined constants or use the static factory methods fromEdits(int) or
+
+    fromString(String) to create instances of the class, while other ctors are
+
+    hidden. This allows for instance control, e.g. returning one of the constants
+
+    when creating instances from an integer value.
+
+    Previously the class would accept any positive integer value and any float
+
+    value, while in effect the maximum allowed edit distance was capped at 2 in
+
+    practice. These values while throw an error now, as will any other String value
+
+    other than "AUTO" that where previously accepted but led to numeric exceptions
+
+    when the query was executed.

docs/changelog/37907.yaml

@@ -0,0 +1,8 @@
+pr: 37907
+issues:
+  - 37897
+area: Search
+type: bug
+summary: Handle total hits equal to `track_total_hits`
+versions:
+  - v8.0.0

docs/changelog/38413.yaml

@@ -0,0 +1,7 @@
+pr: 38413
+issues: []
+area: Infra/REST API
+type: enhancement
+summary: Introduce stability description to the REST API specification
+versions:
+  - v8.0.0

docs/changelog/39328.yaml

@@ -0,0 +1,12 @@
+pr: 39328
+issues: []
+area: Aggregations
+type: breaking
+summary: Remove `MovingAverage` pipeline aggregation
+versions:
+  - v8.0.0
+breaking:
+  notable: false
+  title: Remove `MovingAverage` pipeline aggregation
+  anchor: remove_movingaverage_pipeline_aggregation
+  body: This was deprecated in 6.4.0 and for the entirety of 7.0.  Removed in 8.0 :)

docs/changelog/39346.yaml

@@ -0,0 +1,8 @@
+pr: 39346
+issues:
+  - 39073
+area: Snapshot/Restore
+type: enhancement
+summary: Unify blob store compress setting
+versions:
+  - v8.0.0

docs/changelog/39450.yaml

@@ -0,0 +1,15 @@
+pr: 39450
+issues: []
+area: Aggregations
+type: breaking
+summary: Remove deprecated `_time` and `_term` sort orders
+versions:
+  - v8.0.0
+breaking:
+  notable: false
+  title: Remove deprecated `_time` and `_term` sort orders
+  anchor: remove_deprecated_time_and_term_sort_orders
+  body: >-
+    Deprecated in 6.0, time to go :)
+
+    This isn't really a bugfix so I feel like we missed the boat on 7.0?  Just target 8.0?

docs/changelog/39459.yaml

@@ -0,0 +1,8 @@
+pr: 39459
+issues:
+  - 39350
+area: Engine
+type: upgrade
+summary: Re-enable backwards compatibility
+versions:
+  - v8.0.0

docs/changelog/39593.yaml

@@ -0,0 +1,26 @@
+pr: 39593
+issues:
+  - 39163
+area: Features/ILM+SLM
+type: breaking, enhancement
+summary: Add lower bound on `poll_interval`
+versions:
+  - v8.0.0
+breaking:
+  notable: false
+  title: Add lower bound on `poll_interval`
+  anchor: add_lower_bound_on_poll_interval_
+  body: >-
+    #39163
+
+    Add lower bound on poll_interval
+
+    $ curl -H "Content-Type: application/json" -X PUT -d '{
+      "persistent": {
+        "indices.lifecycle.poll_interval": "1ms",
+        "logger.org.elasticsearch.xpack.indexlifecycle": "TRACE"
+      }
+    }' localhost:9200/_cluster/settings
+
+
+    {"error":{"root_cause":[{"type":"illegal_argument_exception","reason":"failed to parse value [1ms] for setting [indices.lifecycle.poll_interval], must be >= [1s]"}],"type":"illegal_argument_exception","reason":"failed to parse value [1ms] for setting [indices.lifecycle.poll_interval], must be >= [1s]"},"status":400}

docs/changelog/39747.yaml

@@ -0,0 +1,8 @@
+pr: 39747
+issues:
+  - 39525
+area: Highlighting
+type: bug
+summary: Bug fix for `AnnotatedTextHighlighter` - port of 39525
+versions:
+  - v8.0.0

docs/changelog/40033.yaml

@@ -0,0 +1,15 @@
+pr: 40033
+issues: []
+area: Snapshot/Restore
+type: breaking, bug
+summary: Blob Store compress default to true
+versions:
+  - v8.0.0
+breaking:
+  notable: false
+  title: Blob Store compress default to true
+  anchor: blob_store_compress_default_to_true
+  body: |-
+    Changed default of compress setting from false to true for blob store
+    repositories. This aligns the code with documentation and also seems
+    like the better default.

docs/changelog/40379.yaml

@@ -0,0 +1,8 @@
+pr: 40379
+issues:
+  - 40335
+area: Features/CAT APIs, Recovery
+type: bug
+summary: Fix cat recovery display of bytes fields
+versions:
+  - v8.0.0

docs/changelog/40419.yaml

@@ -0,0 +1,28 @@
+pr: 40419
+issues:
+  - 37863
+area: Search
+type: breaking
+summary: Make remote cluster resolution stricter
+versions:
+  - v8.0.0
+breaking:
+  notable: false
+  title: Make remote cluster resolution stricter
+  anchor: make_remote_cluster_resolution_stricter
+  body: >-
+    Remote cluster resolution is currently lenient, to support local
+
+    indices that may contain : in their name. From 8.0 on, there can no
+
+    longer be indices in the cluster that contain : in their name, hence
+
+    we can make remote cluster resolution stricter. Instead of treating
+
+    as local any index expression containing a : whenever there is no corresponding
+
+    matching remote cluster registered, we now throw a
+
+    NoSuchRemoteClusterException.
+
+    Closes #37863

docs/changelog/40496.yaml

@@ -0,0 +1,17 @@
+pr: 40496
+issues: []
+area: Security
+type: breaking, enhancement
+summary: Remove obsolete security settings
+versions:
+  - v8.0.0
+breaking:
+  notable: false
+  title: Remove obsolete security settings
+  anchor: remove_obsolete_security_settings
+  body: |-
+    Removes the deprecated accept_default_password setting.
+    This setting become redundant when default passwords were removed
+    from 6.0, but the setting was kept for BWC.
+    Removes native role store cache settings.
+    These have been unused since 5.2 but were kept for BWC.

docs/changelog/40878.yaml

@@ -0,0 +1,20 @@
+pr: 40878
+issues:
+  - 40755
+area: Infra/Circuit Breakers
+type: breaking, enhancement
+summary: Fixed synchronizing inflight breaker with internal variable
+versions:
+  - v8.0.0
+breaking:
+  notable: false
+  title: Fixed synchronizing inflight breaker with internal variable
+  anchor: fixed_synchronizing_inflight_breaker_with_internal_variable
+  body: >-
+    Tested http://localhost:9200/_nodes/stats/breaker
+
+    and found out that the in flight requests are divided with underscores.
+
+    This is wrong some versions already.
+
+    This is a replacement of pull request #40755 and corrects the printed value in elasticsearch.

docs/changelog/40952.yaml

@@ -0,0 +1,7 @@
+pr: 40952
+issues: []
+area: Engine
+type: upgrade
+summary: Upgrade to lucene 8.1.0-snapshot-e460356abe
+versions:
+  - v8.0.0

docs/changelog/41007.yaml

@@ -0,0 +1,17 @@
+pr: 41007
+issues:
+  - 40303
+area: Reindex
+type: breaking, feature
+summary: Reindex from Remote encoding
+versions:
+  - v8.0.0
+breaking:
+  notable: false
+  title: Reindex from Remote encoding
+  anchor: reindex_from_remote_encoding
+  body: |-
+    Removed the leniency when encoding remote reindex search requests that
+    was introduced in 7.x. All index-names are now encoded before being sent
+    to the remote host.
+    Follow-up to #40303

docs/changelog/41011.yaml

@@ -0,0 +1,39 @@
+pr: 41011
+issues:
+  - 39841
+area: Search
+type: breaking
+summary: Parse empty first line in msearch request body as action metadata
+versions:
+  - v8.0.0
+breaking:
+  notable: false
+  title: Parse empty first line in msearch request body as action metadata
+  anchor: parse_empty_first_line_in_msearch_request_body_as_action_metadata
+  body: >-
+    It looks like when parsing the msearch request body, we allow for the first
+    line to be empty, yet that causes some different treatment for the first
+    line that ends up requiring the action metadata line, while all other lines
+    don't as they can be just empty.
+
+    With this change we properly accept the following which we would otherwise reject due to the first line being empty:
+
+
+    { "query": {"match_all": {}}}
+
+
+    { "query": {"match_all": {}}}
+
+
+    but we stop accepting the following (note the empty line before the first action metadata line:
+
+
+    {}
+
+    { "query": {"match_all": {}}}
+
+
+    { "query": {"match_all": {}}}
+
+
+    Relates to #39841

docs/changelog/41124.yaml

@@ -0,0 +1,9 @@
+pr: 41124
+issues:
+  - 41090
+  - 41091
+area: Machine Learning
+type: bug
+summary: Checking if p-tasks metadata is null before updating state
+versions:
+  - v8.0.0

docs/changelog/41347.yaml

@@ -0,0 +1,7 @@
+pr: 41347
+issues: []
+area: Search
+type: enhancement
+summary: Make 0 as invalid value for `min_children` in `has_child` query
+versions:
+  - v8.0.0

docs/changelog/41492.yaml

@@ -0,0 +1,8 @@
+pr: 41492
+issues:
+  - 40052
+area: Infra/REST API
+type: bug
+summary: "Fix: added missing skip"
+versions:
+  - v8.0.0

docs/changelog/41502.yaml

@@ -0,0 +1,22 @@
+pr: 41502
+issues:
+  - 39845
+  - 35928
+area: Rollup
+type: breaking, enhancement
+summary: "`RollupStart` endpoint should return OK if job already started"
+versions:
+  - v8.0.0
+breaking:
+  notable: false
+  title: "`RollupStart` endpoint should return OK if job already started"
+  anchor: _rollupstart_endpoint_should_return_ok_if_job_already_started
+  body: >-
+    If a job is started or indexing, RollupStart should always return a success
+    (200 OK) response since the job is, in fact, started
+
+    This also removes some no-longer-needed serialization version checking on stop job (only needed for 6.x and 7.x)
+
+    I'm not sure if this should be backported to 7.x.  It's technically a breaking change, but also one that is unlikely to be noticed.  It would only break someone if they were relying on the second invocation of the API to throw the exception so they could do something else.  Thoughts?  I also don't think this is critical, so if this is 8.0+ only that seems fine too.
+
+    Closes #39845 and #35928

docs/changelog/41560.yaml

@@ -0,0 +1,16 @@
+pr: 41560
+issues:
+  - 41164
+area: Analysis
+type: breaking
+summary: Cleanup versioned deprecations in analysis
+versions:
+  - v8.0.0
+breaking:
+  notable: false
+  title: Cleanup versioned deprecations in analysis
+  anchor: cleanup_versioned_deprecations_in_analysis
+  body: |-
+    This commit removes versioned logic in analyzer creation that is no
+    longer relevant for 8.0.
+    relates #41164