x-pack used to generate a trial platinum license on startup, but now it
generates a basic license. Configure security tests to use a trial
license at startup
Original commit: elastic/x-pack-elasticsearch@29382fe5ce
This commit is related to elastic/x-pack-elasticsearch#3877. It allows the passing of a system
property to gradle run indicating whether a `basic` or `trial` license
should be generated. If the `trial` license is indicated, platinum
features will be enabled.
Original commit: elastic/x-pack-elasticsearch@b2b89a4606
This blocks incoming requests from Kibana, Logstash, and Beats when X-Pack monitoring is effectively disabled by setting `xpack.monitoring.collection.interval: -1`.
Original commit: elastic/x-pack-elasticsearch@016a9472f1
The current parsing of errors in the RemoteFailure class is strict and
fails on any field that is not one of [caused_by, reason, root_cause,
stack_trace, type]. Sadly some exceptions adds more headers or
metadata when they are printed as XContent and such fields can't be
easily ignored at parsing time.
This commit changes the RemoteFailure.parseFromResponse() method so that
it parses errors using the same behavior as the high level rest client:
it parses any unknown field as a metadata if it's string value or an
array of string and just ignores and skips everything else without
throwing an exception.
Original commit: elastic/x-pack-elasticsearch@1348706807
Now that the forecast API is available, we can use it to significantly
simplify this test. The test is rewritten to leverage the contract
that when a forecast is requested to a job without state it fails.
relates elastic/x-pack-elasticsearch#3909
Original commit: elastic/x-pack-elasticsearch@978ae352c5
Indices can now specify the catalog (the cluster) in which they belong.
This is a first step in supporting both CCS and BI tools which tend to
be explicit
Original commit: elastic/x-pack-elasticsearch@0b4633facc
In order to prevent exceptions to bubble up to the thread pool exception
handler, this properly wraps all the calls for the watcher service
within an executor into an AbstractRunnable to catch and log a possible
exception.
relates elastic/x-pack-elasticsearch#3854
Original commit: elastic/x-pack-elasticsearch@c0b39e6b5b
* X-Pack-Security: Improve error messaging during setup password
Changes are done to improve logging and exception messages when
setup passwords. Now it checks whether
- X-Pack plugin is available
- X-Pack Security is available
- X-Pack Security is enabled
by invoking /_xpack query and throws a specific error message.
1. Modifications to simple http client to return http response.
2. Changes in SetupPasswordTool for throwing appropriate exceptions.
2. Unit tests
relates elastic/x-pack-elasticsearch#3476
Original commit: elastic/x-pack-elasticsearch@eb0c5a19c5
We were missing a notification for when a job is updated. This is
useful so users know that there's been changes which could justify
a change in the job behaviour.
In addition, having those notifications allows our integrations
tests to know when the update was processed which avoids having
to use `sleep()` with its instabilities.
Original commit: elastic/x-pack-elasticsearch@0b4eda2232
The test `testWatcher()` sometimes fails because the shards are not
active when searching in the `bwc_watch_index` or `.watcher-history`
index. This commit ensured that no shards are relocating or initializing
before executing the searches. It also swallows any error 503 Service
Unavailable when expecting a given number of search hits.
Original commit: elastic/x-pack-elasticsearch@b8e26e0e78
Consolidates type handling into DataType, makes DataType available to
JDBC by moving to sql-proto and removes support for all parameter types
that cannot be handled by the server.
Original commit: elastic/x-pack-elasticsearch@b8024f5c46
Previously this could fail without logging anything, if there was no
exception thrown. Now it records the last status code as well as the last
exception, and logs something either way.
Original commit: elastic/x-pack-elasticsearch@753333e579
This commit introduces a new watcher setting to defer starting watcher
until it has been called with the API for the first time. This is
primarily useful in testing environments, as this ensures that watcher
does not try to reload itself because of starting first and then
creating watcher indices.
In addition the undocumented and unused option
xpack.watcher.start_immediately has been removed.
Relates elastic/x-pack-elasticsearch#3854
Original commit: elastic/x-pack-elasticsearch@2b55aec4ad
This fixes a regression introduced in Elasticsearch 6.0, when switching
from HttpURLConnection to the Apache HTTP Client.
In the old implementation there was no way to specify if you wanted to use HTTP
or HTTPS for your proxy, only HTTP. If people needed to use HTTPs, they
could just use the CONNECT feature of the proxy.
The new implementation used the scheme of the request that was about to
be sent out as the proxy scheme to be used. So if the request was HTTPS
but the proxy server was HTTP this created a problem.
This commit changes the default scheme to be just HTTP, so that then the
standard CONNECT procecure is taken care off.
Without a real proxy server this is super hard to test. I have verified
this with the following test against a tinyproxy running on port 8888,
but I do not have a great idea how to test this in a unit testable way using a real proxy.
Original commit: elastic/x-pack-elasticsearch@f68e72d8f1
The watcher index uses auto expanding of replicas nowadays, so there is
no need to set the number of replicas.
Also ensuring that all watcher indices are green on startup has been moved
to one call, in order to prevent indices being moved around after adding
the triggered watches or watch history index.
Original commit: elastic/x-pack-elasticsearch@dbe04adf64
Snapshot versions before 6.3 do not exist in the public, so they need to
be pulled from snapshots.elastic.co/maven.
Original commit: elastic/x-pack-elasticsearch@3cc94add91
* Add fields to `.logstash`'s mapping in template
This "makes room" in the index for pipeline settings and node groups. Due to this change, users will be able to specify settings and node groups for a pipeline via the Centralized Config Management UI in Kibana. Logstash will only retrieve pipelines associated with the node group specified via the `xpack.management.group.id` setting in `logstash.yml`. For the retrieved pipelines, Logstash will apply any (optionally) specified pipeline settings before (re)loading the pipelines.
* Making field name more explicit + adding multi field for better search
Original commit: elastic/x-pack-elasticsearch@2df101f0b1
This adds the `HEADERS_SETTING` as setting reported by the Monitoring plugin, which was changed in 6.2.
It also adds an IT to ensure that it is not missed in the future (existing integration tests were passing in the Settings and not being validated by the cluster!).
Original commit: elastic/x-pack-elasticsearch@d6f0b4b503