This change deprecates the behavior where security features are
disabled implicitly when the license is basic or trial and the
xpack.security.enabled setting is not explicitly set. The
recommendation is to be explicit in the configuration and either
enable or disable security in elasticsearch.yml.
The `geo_bounding_box` query's `type` parameter is currently ignored and has no
effect on the query. This documents the deprecation of the parameter in 7.14.0.
The parameter will be removed in 8.0.0.
Relates to #70561. Backport of #74008.
Deprecation warning is now issued if any realm is configured with a name
prefixed with an underscore. This applies to all realms regardless
whether they are enabled or not.
Relates: #73250
In #55805, we added a setting to allow single data node clusters to
respect the high watermark. This commit adds deprecation warnings to 7.x
to ensure we can make only true valid in 8.0.
Co-authored-by: David Turner <david.turner@elastic.co>
Recent JDK releases have disabled TLS v1.0 and TLS v1.1 by default
See
- https://java.com/en/jre-jdk-cryptoroadmap.html
- https://bugs.openjdk.java.net/browse/JDK-8202343
This change adds documentation clarifying which TLS versions are
supported on which JDKs (in general terms, rather than specific builds)
and how to change the configuration if necessary.
Also, adds a note to the migration guide for 7.12 and 7.13.
Backport of: #73401
Today when upgrading to the next major version we have a so-called
_major version barrier_: once the cluster comprises nodes of the new
major version then nodes of the previous major version are prevented
from joining the cluster. This means we can be certain that
`clusterState.nodes().getMinNodeVersion().major` will never decrease, so
we can implement upgrade logic that relies on the cluster remaining in
its wholly-upgraded state.
This commit generalises this behaviour to apply to all upgrades, so that
we can be certain that `clusterState.nodes().getMinNodeVersion()` will
never decrease in a running cluster.
Backport of #73358Closes#72911
This commit expands the note about the deprecation of multiple data
paths, adding guidance on how to configure a single filesystem spanning
multiple disks and how to migrate to such a configuration without
downtime.
Closes#71871
We are going to require system call filters. This commit is the first
step in that journey, which is to deprecate the setting that allows
disabling system call filters.
As a precursor for #50892, this PR deprecate the behaviour of file and/or
native realm being implicitly disabled when there are other explicitly
configured realms.
With this change, the recommend way of disabling file/native realm is to
explicitly set enabled to false, e.g.:
xpack.security.authc.realms.file.default_file.enabled: false
This PR ensures that a warning is generated whenever file and/or native realm
is implicitly disabled.
This change also brings a question about the order parameter. Currently, the
order parameter is mandatory in 8.0 and gets a warning message if it is missing
in 7.x. However, it makes sense to not specify the order parameter if the realm
is disabled. So I also updated the order parameter related code to do just
that.
Today we treat all force-merges on a read-only (e.g. frozen) engine as
no-ops, indicating to the client that they succeeded even if they had no
effect. This commit corrects that behaviour, resolving the resulting
confusion, by rejecting force-merges on read-only engines that are
definitely not no-ops.
Co-authored-by: Howard <danielhuang@tencent.com>
Transform writes dates as epoch millis, this does not work for historic data in some cases or is
unsupported. Dates should be written as such. With this PR transform starts writing dates in ISO
format, but as existing transform might rely on the format it provides backwards compatibility for
old jobs as well as a setting to write dates as epoch millis.
fixes#63787
backport #65584
HighlighterUtils.loadFieldValues() loads values directly from the source, and
then callers have to deal with filtering out values that would have been removed
by an ignore_above filter on keyword fields. Instead, we can use the
ValueFetcher for the relevant field, which handles all this logic for us.
Closes#59931.
This syncs breaking changes from release notes
Co-authored-by: Lisa Cawley <lcawley@elastic.co>
Co-authored-by: James Rodewig <40268737+jrodewig@users.noreply.github.com>
(cherry picked from commit 2cc0ccb110)
Signed-off-by: Andrei Dan <andrei.dan@elastic.co>
We removed index-time boosting back in 5x, and we no longer document the 'boost'
parameter on any of our mapping types. However, it is still possible to define an
index-time boost on a field mapper for a surprisingly large number of field types, and
they even have an effect (sometimes, on some queries).
As a first step in finally removing all traces of index time boosting, this comment emits
a deprecation warning whenever a boost parameter is found on a mapping definition.
This commit deprecates the Repository Stats API added in 7.8.0 as
an experimental API behind a feature flag. The goal is to deprecate
this API in 7.10.0 and remove it in a follow up PR in 8.0.0.
This API is now superseded by the Repositories Metering API.
Previously migration guide incorrectly stated that joda-time patterns have to be fixed before upgrading to 7.x
since (7.7) #52555 and our bwc policy 6.x created indices even with joda-time are supported
relates #60374
Per #35284, it looks like we changed this from a max field expansions limit to a soft limit using the `indices.query.bool.max_clause_count` dynamic cluster settting.
