The new subcommand elasticsearch-node remove-index-settings can be used
to remove index settings from the cluster state in case where it
contains incompatible index settings that prevent the cluster from
forming. This tool can cause data loss and its use should be your last
resort.
Relates #96075
This commit introduced stricter DLS rules and is a manual backport of #105709 and #105714
with additional node level settings to optionally disable the stricter DLS rules.
Since these settings are not present in 8.x the needed deprecation info API entries have also
been added to help inform any users that may have set these values to remove them before upgrading.
This setting was removed via #25734, because the setting no longer used
since 6.0.0
However, the validation only kicked when trying to set this setting on a
closed index. Applying the setting on an open index would just work.
With severe consequences later on. For example when upgrading the
cluster, nodes would refuse to boot, because the validation would kick
in.
Relates to #96075
* Update bundled JDK to Java 22 (again) (#108654)
This commit re-bumps the bundled JDK to Java 22 now that we have
a tested workaround for the G1GC bug
(https://bugs.openjdk.org/browse/JDK-8329528).
relates #108571
relates #106987
* copy main openjdk toolchain resolver
* use 2 lines for workaround
* fix test
* update adoptium test
One user reached out mentioning that it would be a good idea to remind
users to re-upload the license after full cluster recovery from snapshot
as one can easily miss this when trying to figure out why some features
aren't working after the restore.
(cherry picked from commit 295fba33d8)
Co-authored-by: Rafi Estrada <62263912+TheRiffRafi@users.noreply.github.com>
Updating repository-hdfs, repository-gcs, and vector-tile to all use the same more recent protobuf.
Co-authored-by: Keith Massey <keith.massey@elastic.co>
Block specific config files from being accessed after startup (#107481)
Some files should never be accessed by ES or plugin code once startup has completed. Use the security manager to block these files from being accessed by anything at all. The current blocked files are elasticsearch.yml, jvm.options, and the jvm.options.d directory.
* SQL: Limit how much space some string functions can use (#107333)
This will check and fail if certain functions would generate a result
exceeding a certain fixed byte size.
This prevents an operation/query to fail the entire VM.
(cherry picked from commit f1bcb338ec)
* Fix use of forbidden APIs
* Style
* [DOCS] Expands the list of possible values of the result parameter of the bulk API. (#107265)
(cherry picked from commit c50fcb95ed)
* Apply suggestions from code review
If the search threadpool fills up then we may reject execution of
`SearchService.Reaper` which means it stops retrying. We must instead
force its execution so that it keeps on going.
With #106542, closes#106543
Backport of #106544 to 7.17
It's possible that a 7.17 master node needs to assign ML jobs
to 8.x ML nodes. Currently this does not work, as the 7.x mechanism
for detecting ML nodes does not work with 8.x ML nodes. Currently
a 7.17 master node will not assign jobs to 8.x ML nodes, so the
jobs sit in limbo until the master node is upgraded to 8.x, and
then they get assigned and pick up where they left off.
This change allows the 7.17 master node to correctly identify 8.x
ML nodes in the cluster, allowing the ML jobs to be reassigned
more quickly during a rolling upgrade from 7.17 to 8.x where
master nodes are upgraded last (as recommended).
These statements come off a little too strongly towards "don't use data streams if you *ever* have updates", but they do support updates when necessary, as long as the backing indices are used.
(cherry picked from commit d95d6adae5)
The docs for forced awareness indicate that no replicas will be assigned
until all zones are available, which is definitely undesirable and also
not the actual behaviour. This commit fixes the wording to match what
really happens.
Closes#104777
* Fix deleting index during snapshot finalization
Today if an index is deleted during a very specific order of snapshot
finalizations then it's possible we'll miscalculate the latest shard
generations for the shards in that index, causing the deletion of a
shard-level `index-UUID` blob which prevents further snapshots of that
shard.
Backports #103817 to 7.17
Closes#101029
* Test fixup
