This makes using usesDefaultDistribution in our test setup for explicit by requiring a reason why it's needed.
This is helpful as part of revisiting the need for all those usages in our code base.
With this, all rolling upgrade tests that involve a
`nextNodeToNextVersion` update are gradle configuration cache
compatible.
Simplify API around test cluster registry and cc compatible usage of
test cluster in TestClusterAware tasks.
Static fields dont do well in Gradle with configuration cache enabled.
- Use buildParams extension in build scripts
- Keep BuildParams.ci for now for easy serverless migration
- Tweak testing doc
The switch to Java 23 removed support for COMPAT locale provider, so
running old versions (< 8.15.2) in a mixed cluster will result in
different results for date format (eg. month and day names are truncated
to three letters).
Fixes https://github.com/elastic/elasticsearch/issues/112617
JDK 23 removes the COMPAT locale provider, leaving CLDR as the only option. This commit configures Elasticsearch
to use the CLDR provider when on JDK 23, but still use the existing COMPAT provider when on JDK 22 and below.
This causes some differences in locale behaviour; this also adapts various tests to still work whether run on COMPAT or CLDR.
Wholesale fix of every `TRAPPY_IMPLICIT_DEFAULT_MASTER_NODE_TIMEOUT` in
`o.e.snapshots` and `o.e.repositories`, just pulling them up to the REST
layer (where they become API params), the test suite (where they become
`TEST_REQUEST_TIMEOUT`), or some other place where an explicit value is
available.
Relates #107984
This commit introduces the concept of shared tests clusters using the
new JUnit testing framework. Unlike normal test clusters which are
exclusive to each test suite (class), shared clusters persist across
test suites to be reused. This can be useful for test projects with a
large number of test suites that can all use a single cluster, and the
overhead of creating these clusters is the dominating factor.
This updates the use of certain exceptions in the QL, EQL and SQL code base. The failures that occur due to either user-provided input (such as incorrect query, incorrect query parameters), or data format not appropriate to the attempted operation (like converting strings to various other types) will now result in a 4xx type code, rather than 5xx.
This change also proposes turning `QlClientException` concrete, by implementing the `status()` method to return a `BAD_REQUEST` (400). The 400 is a "generic", catch-all client-side error message. The other 4xx errors are specializations. No QL code / exception makes use of specializations, but if they so wish, they can simply override the method.
This also makes it clearer to any subclass that a 4xx status must be return.
This change allows the use of some currently abstract subclasses, such as `EqlClientException`, which can be employed on user-related failures, that are currently inappropriately raised as a form of `QlIllegalArgumentException`, which is a 500-type error.
Also, an `InvalidArgumentException` extending `QlClientException` is introduced, being thrown where the execution cannot continue due to user's query (either direct input or invalid application of functions to index data).
* Mixed cluster tests with string NodeInfo version
- Move version based feature comparison to a common, deprecated method (to be replaced with real features)
- Use string comparison against old cluster version to partition new/old cluster nodes
Some tests rely on the natural index order for test assertions. This
works when the index has a single primary shard but fails otherwise.
This PR adjusts the relevant tests so that they explicitly configure the
number of shards to 1.
Relates: ES-6540
Another round of automated fixes to this, marking things that can be
made static as static. Saves some JIT cycles but also turns some lambdas
from capturing to non-capturing and makes the "utilityness" of some
classes visible.
Lots of spots where we did weird things around streams like redundant stream creation, redundant collecting
before adding all the collected elements to another collection or so, redundant streams for joining strings
and using less efficient `Collectors.toList` and in a few cases also incorrectly relying on the result being mutable.
We want to be able to tweak client configuration in tests extending
ESRestTestCase. This makes that simpler by allowing overriding the
general client configuration.
sequence with maxspan=10m
[ event where name = 'a' ]
![ event where name = 'b' ]
[ event where name = 'c' ]
meaning "find 'a' and 'c', in a 10 minutes span, where no 'b' exists in between"
For non-wildcard resource names in expressions from requests with the
`ignoreUnavailable` request option set to `true`, the Security filter
removes names for "unavailable" resources. This behavior is
theoretically correct, but in practice the cluster state might not be
recovered at the point in time when the Security filter does the
rewrite (this causes problems, see #90215); In any case, the logic
to remove "unavailable" names is unnecessarily duplicated from
Core's expression resolver.
This PR makes the expression resolver in the Security filter to NOT:
* remove missing but authorized names (indices, aliases, datastreams)
* remove authorized datastreams if context disallows datastreams
* remove backing indices of authorized datastreams if context disallows datastreams
It will only remove names of unauthorized resources, and let the
unavailable names go through to be handled (to be ignored or
throw "not found" exception) by the expression resolver in Core.
Fixes: #90215
This commit adds a new test framework for configuring and orchestrating
test clusters for both Java and YAML REST testing. This will eventually
replace the existing "test-clusters" Gradle plugin and the build-time
cluster orchestration.
Removing the custom dependency checksum functionality in favor of Gradle build-in dependency verification support.
- Use sha256 in favor of sha1 as sha1 is not considered safe these days.
Closes https://github.com/elastic/elasticsearch/issues/69736
