This commit moves the source file in x-pack-core to a org.elasticsearch.xpack.core package. This is to prevent issues where we have compile-time success reaching through packages that will cross module boundaries at runtime (due to being in different classloaders). By moving these to a separate package, we have compile-time safety. Follow-ups can consider build time checking that only this package is defined in x-pack-core, or sealing x-pack-core until modules arrive for us.
Original commit: elastic/x-pack-elasticsearch@232e156e0e
Adds documentation for all of the date time functions using the new
cli-like format extracted from the csv spec. In the process of doing
this I noticed that the `WEEK` function isn't exposed as a function.
This exposes it for consistency.
Relates to elastic/x-pack-elasticsearch#2898
Original commit: elastic/x-pack-elasticsearch@0459b24cb9
I went to write some docs for datetime functions that look like:
```
SELECT YEAR(CAST('2018-01-19T10:23:27Z' AS TIMESTAMP)) as year;
year
2018
```
because I figured they'd be pretty easy to read because they didn't
require any knowledge of a data set. But it turns out that constant
folding doesn't work properly for date time functions because they don't
actually apply the extraction.
Original commit: elastic/x-pack-elasticsearch@aa9c66b2c7
This commit adds the ability to refresh tokens that have been obtained by the API using a refresh
token. Refresh tokens are one time use tokens that are valid for 24 hours. The tokens may be used
to get a new access and refresh token if the refresh token has not been invalidated or
already refreshed.
relates elastic/x-pack-elasticsearch#2595
Original commit: elastic/x-pack-elasticsearch@23435eb815
* Security Realms: Predictable ordering for realms
To have predictable ordering of realms, by having secondary
sorting on realm name resulting in stable and consistent documentation.
Documentation update describing how ordering of realms is determined.
Testing done by adding unit test for the change, ran gradle clean check locally.
relates elastic/x-pack-elasticsearch#3403
Original commit: elastic/x-pack-elasticsearch@98c42a8c51
Adds a mode parameter to all SQL-related requests. The mode parameter is used for license checks as well as to define the response content. For now only two modes are supported plain (default) and jdbc. We will add other modes in the future as we add more clients.
Relates elastic/x-pack-elasticsearch#3419
Original commit: elastic/x-pack-elasticsearch@b49ca38d4b
* SQL: Move shared REST client methods to shared-client
This commit is a preliminary step for moving JDBC to the REST client. It extracts the common REST clients from CLI and moves it to shared-client. This will allow us to move to the 5 project setup: rest-proto, shared-client, server, jdbc, cli with the following dependencies:
server <-- rest-proto
shared-client <-- rest-proto
jdbc <-- shared-client
cli <-- shared-client
Relates to elastic/x-pack-elasticsearch#3419
Original commit: elastic/x-pack-elasticsearch@2e6a134de0
* Starts to build the list of supported functions, adding links to
wikipedia when there is any doubt what the functions mean.
* Extracts an example of using the function from the test suite.
* Explicitly calls out how we round (half up) because there are
lots of ways to round.
Original commit: elastic/x-pack-elasticsearch@5fb64ba869
* Remove "overview". That is already covered in the index page.
* Write a basic getting started page.
* Fix the CLI startup instructions.
Original commit: elastic/x-pack-elasticsearch@dabe72b5cc
The index action allowed to set the id of a document dynamically,
however this was not allowed for the index or the type.
If a user wants to execute a search, modify the found documents and
index them back, then this would only work across a single index and a
single type. This change allows the watch writer to just take a search
result, read index and type out of that and configure this as part of
the index action.
On top of that the integration tests have been changed to become fast
running unit tests.
Original commit: elastic/x-pack-elasticsearch@640b085dd4
This commits adds a new end point for closing in-flight cursors, it also ensures that all cursors are properly closed by adding after test checks that ensures that we don't leave any search context open.
relates elastic/x-pack-elasticsearch#2878
Original commit: elastic/x-pack-elasticsearch@1052ea28dc
The example Docker Compose file does not quote the version value however
the Docker Compose documentation specifies this value should be quoted
to distinguish it from being treated as a number.
Relate elastic/elasticsearch#27745
Original commit: elastic/x-pack-elasticsearch@42ad68c3ac
This PR uses a new extension point that's being added to Elasticsearch (see https://github.com/elastic/elasticsearch/pull/27603) so that the security plugin can filter the mappings fields returned by get index, get mappings, get field mappings and field capabilities API.
This effort aims at filtering information returned by API in the `indices/admin` category and field capabilities. It doesn't filter what the cluster state api returns as that is a cluster level operation.
One question is about backwards compatibility given that we would like to have this in 6.2. Shall we treat this as a bug as mappings should have been filtered before? Not sure if it's going to break existing integrations.
relates elastic/x-pack-elasticsearch#340
Original commit: elastic/x-pack-elasticsearch@d7e3fd3fa1
The pagerduty action allows to send contexts, which contains an array
of texts or images, each with a link.
The field of this data was named 'context' instead of 'contexts' and
thus those contects were never correctly parsed on the pagerduty side.
Unfortunately pagerduty accepts any JSON, thus this was not caught so
far.
This commit allows parsing of the old field name to retain BWC, but when
written out via toXContent, it will always use the 'contexts' field name.
relates elastic/x-pack-elasticsearch#3184
Original commit: elastic/x-pack-elasticsearch@50f0b65d56
* [DOCS] Refreshed ML screenshots
* [DOCS] Added screenshots for ML Data Visualizer
* [DOCS] Addressed feedback about data visualizer
* [DOCS] Fixed typo in ML tutorial
Original commit: elastic/x-pack-elasticsearch@2603536a93
* [DOCS] Refresh screenshots in ML tutorial
* [DOCS] Refreshed screenshots for single metric job
* [DOCS] Removed outdated index screenshot
Original commit: elastic/x-pack-elasticsearch@14f39c3091
* [DOCS] Subdivided getting started with ML pages
* [DOCS] Added new getting started page to build.gradle
Original commit: elastic/x-pack-elasticsearch@968187b048
Following the changes of elastic/x-pack-elasticsearch#2975 the hard limit on the number of ML jobs
per node is no longer the only limiting factor. Additionally there is
now a limit based on the estimated memory usage of the jobs, and this is
expected to provide a more sensible limit that accounts for differing
resource requirements per job.
As a result, it makes sense to raise the default for the hard limit on
the number of jobs, on the assumption that the memory limit will prevent
the node becoming overloaded if an attempt is made to run many large jobs.
Increasing the hard limit will allow more small jobs to be run than was
previously the case by default.
Of course, this change to the default will have no effect for customers
who have already overridden the default in their config files.
Original commit: elastic/x-pack-elasticsearch@9fed1d1237