This changes the way that Kibana (and future applications) send their monitoring stats to Elasticsearch.
Instead of sending their payloads with the System ID (e.g., "kibana") and System Version (e.g., "5.0.0-alpha4"), it now expects the System ID and System _API_ Version (e.g., "2"). This means a few things:
- Future releases are automatically compatible with previous releases as long as the API version doesn't change.
- Users don't have to update Kibana at the exact same time as their cluster (which technically means rolling updates were temporarily blockers of Kibana monitoring before).
- We can accept old API versions (if we need to make a breaking change) and automatically up-convert them to the latest API version. (We are in full control of how far back we choose to accept)
In general, this change implies that users should be updating their Monitoring cluster before their _monitored_ cluster(s) to get the best opportunity of monitoring backwards compatibility. That way if any API change does occur, then it can up-convert as needed. Then, any ES node should be updated, and only then should Kibana be updated. This is not required in any way, but it will give the smoothest experience.
Original commit: elastic/x-pack-elasticsearch@d3c24936e1
While testing another PR, I noticed that when Security is disabled, the _xpack/usage API throws a NullPointerException.
This checks for null before using it, and adds tests to verify behavior.
Original commit: elastic/x-pack-elasticsearch@6474af6569
When a painless exception is raised in the script condition, it was not bubbled up due to
catching exceptions on during execution. This removes the different catching of exceptions
and allows the watch record construct to contain an exception that is also serialized correctly
so that it can be stored in the watch history but also returned in the execute watch API.
This also updates the watch history template, so that exceptions are not indexed, but logged.
Relates elastic/elasticsearch#2587
Original commit: elastic/x-pack-elasticsearch@4dffb672bf
The top-level class Throwable represents all errors and exceptions in
Java. This hierarchy is divided into Error and Exception, the former
being serious problems that applications should not try to catch and the
latter representing exceptional conditions that an application might
want to catch and handle. This commit renames
org.elasticsearch.cli.UserError to org.elasticsearch.UserException to
make its name consistent with where it falls in this hierarchy.
Relates elastic/elasticsearch#2701
Original commit: elastic/x-pack-elasticsearch@589e159ec0
Today throughout the codebase, catch throwable is used with reckless
abandon. This is dangerous because the throwable could be a fatal
virtual machine error resulting from an internal error in the JVM, or an
out of memory error or a stack overflow error that leaves the virtual
machine in an unstable and unpredictable state. This commit removes
catch throwable from the codebase and removes the temptation to use it
by modifying listener APIs to receive instances of Exception instead of
the top-level Throwable.
Relates elastic/elasticsearch#2694
Original commit: elastic/x-pack-elasticsearch@7ecdd7d978
This looks like it predates settings validation in core, and only had a
single use inside the watcher ExecutionService. This change moves the
settings inside ExecutionService to be validated settings, and removes
the watcher specific validation.
Original commit: elastic/x-pack-elasticsearch@82843ce56c
When a license exception is raised, we returned 401 as HTTP error code
in there. However this seems to have triggered some browsers to actually
ask for login credentials, which wont have any impact here.
Closeselastic/elasticsearch#1863
Original commit: elastic/x-pack-elasticsearch@cc63abdac8
We are going to parse the body anyways whenever it's in json format as it is going to be stashed. It is not useful to lazily parse it anymore. Also this allows us to not rely on automatic detection of the xcontent type based on the content of the response, but rather read the content type from the response headers.
Original commit: elastic/x-pack-elasticsearch@11be4684ae
The internal representation of the object that JsonPath gives access to is a map. That is independent of the initial input format, which is json but could also be yaml etc.
This commit renames JsonPath to ObjectPath and adds a static method to create an ObjectPath from an XContent
Original commit: elastic/x-pack-elasticsearch@bc84c68161
Currently, the REST tests for security (and possibly others) don't clean up the environment
after they have run, eg. they don't delete the users and roles they create. This leads to
test failures, because in a subsequent run, a user or role already exists, so eg. a test
like `match: { role: { created: true } }` fails.
This patch adds a `teardown` section to the test, with `do` actions which are to be
executed _after_ the test runs.
This patch assumes that REST tests runners for all languages support the `teardown` directive
in a xUnimt nomenclature -- similarly to the `setup` directive, which they already support.
Original commit: elastic/x-pack-elasticsearch@70d0ff4ee9
This is the xplugins side of moving the client dependency for rest
handlers to the handleRequest method
Original commit: elastic/x-pack-elasticsearch@ce66e35e7b
Robert Muir
Chris Earle
Ryan Ernst
Jason Tedor
Adrien Grand
jaymode
Alexander Reelsen
Boaz Leskes
Tanguy Leroux
Colin Goodheart-Smithe
Nik Everett
Simon Willnauer
javanna
Jay Modi
Lee Hinman
Karel Minarik
Martijn van Groningen