`index.mapper.single_type` will be removed in master. While there is still
one usage in the security template that we are working on, this change
will remove the remaining usage.
Original commit: elastic/x-pack-elasticsearch@6e7f63b9e0
This is just a workaround at the moment, but allows to use
mustache if you only provide the `url` part of a request,
instead of scheme, port, path, host, etc.
Original commit: elastic/x-pack-elasticsearch@3a4aa26665
Every cluster state update resulted in a log message, that watcher
pauses execution. This has been fixed to only log, if there was an
actual state switch from executing to pausing, but do nothing if
there are no local shards anyway.
This will reduce the logging noise in tests a lot.
Original commit: elastic/x-pack-elasticsearch@32ab86610c
* Give kill a chance to kill the process before closing input
* Remove variable that can be refactored out
Original commit: elastic/x-pack-elasticsearch@42f7a3cece
The graph API needs to be able to search in remote indices. Although it uses the Search API to perform the search and so doesn’t need to deal with remote indexes directly, the security feature needs to know it can be used with remote indexes so it knows to include remote indices in the list of indices accessible from the API for index level security
Original commit: elastic/x-pack-elasticsearch@e3cd84963e
This change removes all local security checks against remote cluster names.
Any user is allowed to attempt a cross-cluster search, and it is the responsibility of the remote cluster to authorise the search (or not).
This includes support for remote searches even if you have _no_ local search privileges.
Original commit: elastic/x-pack-elasticsearch@1620c3a8fa
Currently, aggregated datafeeds construct JSON from the aggregation
response by traversing all nested aggregations. In order to
achieve this, multiple leaf aggregations are not supported. Also,
scenarios it makes it impossible to effectively use pipeline
aggregations as it will not ignore the intermediate bucket
aggregations.
This commit refactors AggregationToJsonProcessor in order to
support the above scenarios. This is achieved by only converting
the fields of interest, that is the job analysis fields.
Original commit: elastic/x-pack-elasticsearch@8b575956ca
This changes the validation criteria we use for user and role
names in the file realm, native realm, and the
realm-agnostic code in x-pack security. The new criteria is:
A valid username's length must be at least 1 and no more than 1024
characters. It may not contain leading or trailing whitespace. All
characters in the name must be be alphanumeric (`a-z`, `A-Z`, `0-9`),
printable punctuation or symbols in the https://en.wikipedia.org/wiki/Basic_Latin_(Unicode_block)[Basic Latin (ASCII) block],
or the space character.
Original commit: elastic/x-pack-elasticsearch@f77640f269
Today we have some hidden complexity related to default configurations
might specify NO_KEY which is in some cases valid for server configuration.
This change removes the leniencey paramenters on the validation methods and removes
obsolet asserts.
Original commit: elastic/x-pack-elasticsearch@17ed4b1d20
You can now disable cluster alerts in the local exporter, which you can do in the HTTP exporter already.
This helps users that mess up their watcher configuration (e.g., disabling scripts) can turn off the feature to avoid log spam.
Original commit: elastic/x-pack-elasticsearch@f2096b553d
The cluster alert did not get updated when we dropped the logical 'type' for cluster_state in favor of merging it with cluster_stats in 5.5+.
Original commit: elastic/x-pack-elasticsearch@c7105be36f
Today we parse / construct SSLConfiguration late when client / server
channels are created. This is problematic if we try to read from secure settings
in the future since we need to read all secure settings as soon as the node is
constructed. If we keep on reading late, we will access a closed keystore
since channel creation happens during node startup.
Original commit: elastic/x-pack-elasticsearch@78d6061990
If the internal index version of an index is not the right one, do
not start watcher.
Also, add the internal index version of 6 to all our index templates.
Original commit: elastic/x-pack-elasticsearch@20b50aa82b
If multiple job deletion requests were sent in quick succession, there was a
race condition that meant they could both get through the check to enforce
one active deletion request at a time. Then, if the job was immediately
recreated after the first deletion request returned, the second, still running,
deletion request could interfere with it and delete the aliases that the put
job request created.
This problem can be avoided by using the "ask forgiveness, not permission"
idiom when checking if the job is already being deleted at the beginning of
each deletion request.
Additionally, now even force delete requests will wait for a certain amount
of time for a prior delete request to complete. This is to avoid the same
race conditions. However, force delete requests will eventually start an
(unsafe) parallel delete to provide a get-out in case a delete request
completely dies.
relates elastic/x-pack-elasticsearch#1765
Original commit: elastic/x-pack-elasticsearch@b5c8f26a0e
The current testing setup only checked if watcher was started, but it
also needs to check for the index template in order to be sure that
everything is set up correctly, before trying to put a watch.
relates elastic/x-pack-elasticsearch#1762
Original commit: elastic/x-pack-elasticsearch@3ed78b15a1
This commit changes a couple of places where our ExceptionsHelper
class was throwing exceptions to instead return the exceptions.
Then they can be passed to onFailure() methods or thrown depending
on what's appropriate for the caller. This is the standard Elastic
way of handling failures.
Original commit: elastic/x-pack-elasticsearch@fce07eb075
This allows to configure a proxy for the reporting attachment
action. The proxy is used by the HTTP client.
Original commit: elastic/x-pack-elasticsearch@87b6ab1b68
The MockTerminal used in tests uses \n always and the reverted commit re-introduced the bug which
had been fixed earlier.
Original commit: elastic/x-pack-elasticsearch@09b93b5565
This change enables closing a job while it is in
the middle of restoring its state. This is has the
benefit of allowing users to close jobs that due to
relocation are `opened` but they are still restoring
state. It also helps avoiding race conditions in tests.
Part of this change also includes restoring the state
as a separate step from the process creation. This means
we no longer block the job map while the process is
restoring its state.
relates elastic/x-pack-elasticsearch#1270
Original commit: elastic/x-pack-elasticsearch@1713a4a7c4
In cases where the job is bound on the analytics performance
the datafeed can fail because the scroll expires. This is
commit increases the scroll context duration from 10 to 30 minutes
as a temporary solution that will avoid most cases.
Original commit: elastic/x-pack-elasticsearch@fd277bbaa1
This changes the native realm migrate tool tests to use the System.lineSeperator instead of `\n`
so that the tests will pass on Windows.
Original commit: elastic/x-pack-elasticsearch@d3f9a71ac4
Prior to this change, if the persistent tasks framework noticed that a
job was running on a node that was isolated but has rejoined the cluster
then it would close that job. This was not ideal, because then the job
would persist state from the autodetect process that was isolated. This
commit changes the behaviour to kill the autodetect process associated
with such a job, so that it does not interfere with the autodetect process
that is running on the node where the persistent tasks framework thinks it
should be running.
In order to achieve this a change has also been made to the behaviour of
force-close. Previously this would result in the autodetect process being
gracefully shut down asynchronously to the force-close request. However,
the mechanism by which this happened was the same as the mechanism for
cancelling tasks that end up running on more than one node due to nodes
becoming isolated from the cluster. Therefore, force-close now also kills
the autodetect process rather than gracefully stopping it. The documentation
has been changed to reflect this. It should not be a problem as force-close
is supposed to be a last resort for when normal close fails.
relates elastic/x-pack-elasticsearch#1186
Original commit: elastic/x-pack-elasticsearch@578c944371