* Add integration tests that verify ST_EXTENT_AGG needs a license (#125584) (#125712)
* Fix java version problem on backport
* Use PLATINUM as license level for spatial features
In #120505 we introduced a capabilities check in the yaml test `deprecation/10_basic/Test Deprecations` but we forgot to add them in the `RestDeprecationInfoAction`.
In this PR we add the capabilities which will enable the test and we make the test resilient to the warning that occurs when the `.security-7` index is present.
Load field caps from store if they haven't been initialised through a refresh yet.
Keep the plain reads to not mess with performance characteristics too much on the good path but protect against confusing races when loading field infos now (that probably should have been ordered stores in the first place but this was safe due to other locks/volatiles on the refresh path).
Closes#125483
For creating and deleting projects in multi-project tests, we need
create and delete settings and secrets files on the fly. This PR adds
such feature to the Java test cluster with an option to specify the
config directory.
(cherry picked from commit a1b0ed104b)
Co-authored-by: Yang Wang <yang.wang@elastic.co>
Follow up to #125345. If the query contained both a nanos and a millis comparison, we were formatting the dates incorrectly for the lucene push down. This PR adds a test and a fix for that case.
---------
Co-authored-by: elasticsearchmachine <infra-root+elasticsearchmachine@elastic.co>
Fixes#125439
We were incorrectly formatting nanosecond dates when building lucene queries. We had missed this in our testing because none of the CSV tests were running against Lucene. This happened because the date nanos test data includes multivalue fields. Our warning behavior for multivalue fields is inconsistent between queries run in Lucene and queries run in pure ES|QL without pushdown. Our warning tests, however, require that the specified warnings be present in all execution paths. When we first built the date nanos CSV tests, we worked around this by always using an MV function to unpack the multivalue fields. But we forgot that using an MV function prevents the entire query from being pushed down to Lucene, and thus that path wasn't being tested.
In this PR, I've duplicated many of the tests to have a version that doesn't use the MV function, and uses warningRegex instead of warning. The regex version does not fail if the header is absent, so it's safe to use in both modes. Rewriting the tests this way revealed several situations in which this bug can manifest, all of which are fixed in this PR. I cannot be confidant that there aren't more paths that can trigger this bug and aren't covered by these tests, but I haven't found any yet.
I've left some trace level logging that I found helpful while debugging this.
---------
Co-authored-by: elasticsearchmachine <infra-root+elasticsearchmachine@elastic.co>
This commit adds a new command line option to the run task to include
plugins. The option takes in a comma separated list of plugins from the
plugins directory. For example:
```
./gradlew run --with-plugins=analysis-icu,analysis-nori
```
* Update service-openai.asciidoc (#125419)
Many customers want to use our OpenAI Inference endpoint against OpenAI compatible API's they have written, or Ollama, or Nvidia Triton OpenAI API front end. I had heard that was the intent of this OpenAI inference endpoint, but we do not state it directly. Can we validate this is OK with Search PM and include this?
Co-authored-by: István Zoltán Szabó <istvan.szabo@elastic.co>
* Update docs/reference/inference/service-openai.asciidoc
---------
Co-authored-by: Brad Quarry <38725582+bradquarry@users.noreply.github.com>
* Adds explanation on the delay parameter
* Attribute fixes
* Update docs/reference/transform/usage.asciidoc
---------
Co-authored-by: István Zoltán Szabó <istvan.szabo@elastic.co>
This PR adds a check and a warning message if the user is trying to install a plugin containing the legacy plugin-security.policy used by SecurityManager.
Relates to ES-10846
Since #122905 we were throwing NPEs (i.e. 5xxs) when a rollover request has an unknown/non-existent target. Before that, we returned a 400 - illegal argument exception. We now return a 404 which matches "missing target" better. Additionally, to avoid this from happening again, we add a YAML test that asserts the correct exception behavior.
(cherry picked from commit fdd453734d)
# Conflicts:
# server/src/main/java/org/elasticsearch/action/admin/indices/rollover/MetadataRolloverService.java
* Move remaining check methods in RestEntitlementsCheckAction (#125351)
All future check methods should be found reflectively with the
EntitlementTest annotation.
* Fix compilation after #125442
