* [DOCS] Add ML geographic functions
* [DOCS] Add script_fields info to ML geo functions
* [DOCS] Remove summary count from ML geographic functions
* [DOCS] Added example title to geographic functions
* [DOCS] Remove list from ML geographic functions
Original commit: elastic/x-pack-elasticsearch@a8e495657f
* Add sort parameter for get buckets
* Add secondary sort by time
* Use default values from actions in rest requests
Original commit: elastic/x-pack-elasticsearch@a530c0bed6
* [DOCS] Add script_fields to ML datafeed APIs
* [DOCS] Add datafeedresource.asciidoc to build.gradle
* [DOCS] Addressed feedback in PR 1372
Original commit: elastic/x-pack-elasticsearch@3404ca7850
* [DOCS] Add ML analytical functions
* [DOCS] Add pages for ML analytical functions
* [DOCS] Add links to ML functions from API definitions
Original commit: elastic/x-pack-elasticsearch@ae50b431d3
As fields with underscores will be disallowed in master, and we have to
prepare the upgrade, this commit renames the _status field to status.
When the 5.x upgrade logic is in place in the 5.x we can remove all the
old style _status handling from the master branch.
Note: All the BWC compatibility tests, that load 5.x indices are now
faking a finished upgrade by adding the `status` field to the mapping
of the watches index.
Original commit: elastic/x-pack-elasticsearch@9d5cc9aaec
* [DOCS] Add property table for ML Update Jobs API
* [DOCS] Updates based on feedback for ML Update Jobs API
* [DOCS] Removed detector properties from ML Update Jobs API
* [DOCS] Fixes typos
Original commit: elastic/x-pack-elasticsearch@68d1b5598c
The distribution of watches now happens on the node which holds the
watches index, instead of on the master node. This requires several
changes to the current implementation.
1. Running on shards and replicas
In order to run watches on the nodes with the watches index on its
primaries and replicas. To ensure that watches do not run twice, there is
a logic which checks the local shards, runs a murmurhash on the id and
runs modulo against the number of shards and replicas, this is the way to
find out, if a watch should run local. Reloading happens
2. Several master node actions moved to a HandledTransportAction, as they
are basically just aliases for indexing actions, among them the
put/delete/get watch actions, the acknowledgement action, the de/activate
actions
3. Stats action moved to a broadcast node action, because we potentially
have to query every node to get watcher statistics
4. Starting/Stopping watcher now is a master node action, which updates
the cluster state and then listeners acts on those. Because of this watches
can be running on two systems, if you those have different cluster state
versions, until the new watcher state is propagated
5. Watcher is started on all nodes now. With the exception of the ticker
schedule engine most classes do not need a lot of resources while running.
However they have to run, because of the execute watch API, which can hit
any node - it does not make sense to find the right shard for this watch
and only then execute (as this also has to work with a watch, that has not
been stored before)
6. By using a indexing operation listener, each storing of a watch now
parses the watch first and only stores on successful parsing
7. Execute watch API now uses the watcher threadpool for execution
8. Getting the number of watches for the stats now simply queries the
different execution engines, how many watches are scheduled, so this is
not doing a search anymore
There will be follow up commits on this one, mainly to ensure BWC compatibility.
Original commit: elastic/x-pack-elasticsearch@0adb46e658
* [DOCS] Add ML limitations
* [DOCS] Address feedback about ML limitations
* [DOCS] Change ML limitations capitalization
Original commit: elastic/x-pack-elasticsearch@41682d8d93