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.
Keepalive options are not well-documented (only in transport section, although also available at http and network level).
Co-authored-by: David Turner <david.turner@elastic.co>
Co-authored-by: James Rodewig <40268737+jrodewig@users.noreply.github.com>
This PR contains the deprecation notice that `create`, `create_doc`, `index` and
`write` ingest privileges do not permit mapping updates in version 8. It also
updates the docs description of said privileges.
This should've been part of #58784
This improves modularity and also fixes some issues when `docvalues_fields` is
used within `inner_hits` or the `top_hits` agg:
* We previously didn't resolve wildcards in field names.
* We also forgot to enforce the limit `index.max_docvalue_fields_search`.
Today `GET _nodes/stats/fs` includes `{least,most}_usage_estimate`
fields for some nodes. These fields have rather strange semantics. They
are only reported on the elected master and on nodes that have been the
elected master since they were last restarted; when a node stops being
the elected master these stats remain in place but we stop updating them
so they may become arbitrarily stale.
This means that these statistics are pretty meaningless and impossible
to use correctly. Even if they were kept up to date they're never
reported for data-only nodes anyway, despite the fact that data nodes
are the ones where we care most about disk usage. The information needed
to compute the path with the least/most available space is already
provided in the rest the stats output, so we can treat the inclusion of
these stats as a bug and fix it by simply removing them in this commit.
Since these stats were always optional and mostly omitted (for opaque
reasons) this is not considered a breaking change.
Backport of #58898.
Part of #48366. Now that there is a dedicated API for dangling indices, the auto-import
behaviour can default to off. Also add a note to the breaking changes for 7.9.0.
