Enables filtering out sensitive settings from the nodes info API rest endpoint. Also provide a mechanism to filter out additional settings via a new `shield.hide_settings` setting.
Original commit: elastic/x-pack-elasticsearch@9bab5049e7
On Windows, ensureGreen times out due to some shards not being initialized so
this increases allocation logging.
Original commit: elastic/x-pack-elasticsearch@e3777a8e89
After the switch from elasticsearch.com to elastic.co, these tests started failing
due to socket connect errors. Now we will just connect to the OpenLDAP server
which should be a different machines than the ones running tests.
Original commit: elastic/x-pack-elasticsearch@7bf713a313
The idea behind a time warp mode is that while it's enabled the time related constructs in the alerts module are replaced with a mock test friendly version.. so we'll be able to control time and therefore avoid sleeping the threads.
In time warp mode:
- The `SchedulerMock` is used to manually fire jobs
- The `ClockMock` is used to set and fast forward time
- The alerts are executed on the same thread as the scheduler mock... so we don't have to deal with async nature at all. This is accomplished by the added `AlertsExecutor` abstraction.
By default, the time warp mode is enabled and tests run in it. If a test must not use the time warp mode, it is possible to add `@TimeWarped(false)` annotation to the test and it will then run with the standard scheduler & clock. It is also possible to disable this mode all together by running the tests with `-Dtests.timewarp=false`.
All the updated tests now work in both modes (whether the time warp mode is dis/enabled). This is important as on the server we would like to run the tests outside of this mode as well, but locally we'd like to run them with time warped enabled (so they'll be faster)
Also, cleaned up the tests.. we now only do `assertThat(...)` calls (no `assertTrue` or `assertEquals`... for consistency sake)
Original commit: elastic/x-pack-elasticsearch@11e09f6dea
The resolved anonymous user was not added to the REST request context. This resulted in that when the request was "translated" to a transport request, the fallback was the `system user`. The commit fixes that.
Original commit: elastic/x-pack-elasticsearch@acea6becf1
Any exception caught during authentication is only logged if DEBUG is enabled.
This changes the behavior to log these exceptions are WARN with the exception
message only or at DEBUG with the full exception.
The user template ldap implementation could potentially cause a lot of
logging to be generated because it always prints the full exception at WARN
level. This changes it to print the message at WARN level and the exception
at DEBUG.
Original commit: elastic/x-pack-elasticsearch@c607567d88
Use in:
- Determining the execution time of an alert
- The period throttler to determine the time passed since last execution
Original commit: elastic/x-pack-elasticsearch@9197b86b68
- the transform parser and registry can now parse transform results
- every transform result may have its own format
- the chain transform result outputs the "transformation trail" of all the chained transforms (great tool for debugging)
- removed `Transform.NOOP` - was redundant, when no transform is defined the alert's transform is `null`
- removed `payload` from the `AlertExecution`. Instead, the execution holds the input result, transform result and potentially the transform results of the actions
- changed the xcontent representing a transofrm result to `{ "transform_type" : { "payload" : {...}, ... } }`
- with this change, the `Action` interface is cleaned up (`execute` only accepts the execution context)
Original commit: elastic/x-pack-elasticsearch@6ecf7f2c92
An alert may have multiple actions associated with it, but each action may need to have different view of the data. For example, the email may need a certain model for its templates while the index or webhook actions may need a completely different data structure.
Until now, there's only an option to defina a single `transform` on the alert level that would have applied to all actions. This commit adds
the ability to associate a transform with each action. We still keep the tranform on the alert level (in case all actions need the same transformation, in which case we'd like to avoid repetition).
Original commit: elastic/x-pack-elasticsearch@5493a2179b
Now `Variables.createCtxModel` is responsible for creating the model for scripts & templates across the board. Accessing the payload, alert name, fired time and scheduled fire time is done via the `ctx.` prefix.
Original commit: elastic/x-pack-elasticsearch@443ac17579
Now the script's params in the `script` condition are merged with the payload data into a single variable context to the script execution. The payload data is now accessed using the `payload.` prefix.
Original commit: elastic/x-pack-elasticsearch@e313a6301c
This change filters out unsupported ciphers before setting the ciphers on the
SSLEngine. The unsupported ciphers are logged in a message at the error
level. If none of the specified ciphers are supported, then an exception will
be thrown.
Closeselastic/elasticsearch#698
Original commit: elastic/x-pack-elasticsearch@68cf47ec19
In order to be able to configure ip filtering in a dynamic way, all
the ip filter related settings have been made dynamic.
This commit also fixed a bug, as the setting shield.http.filter.enabled
was not working, but mentioned in the documentation.
Documentation has been updated along the way.
Closeselastic/elasticsearch#697
Original commit: elastic/x-pack-elasticsearch@2760c47b5b
The `AlertSourceBuilder` along with a set of source builder for all the different constructs that make an alert (condition, input, transform and action), provides a structured approach for building an alert from the client side (instead of forcing the clients to use xcontent directory)
- fixed some of the tests to already use these builders (I reckon there are still quite a few that need to be converted.. but we'll do that over time).
- moved all integration tests under `test/integration` package.
- changed the `AlertsTests` to **not** be an integration test... it randomizes the alert structure and makes sure that it can serialize & deserialize itself to/from xcontent.
- fixed small bugs found by the tests
Original commit: elastic/x-pack-elasticsearch@94b76b6fc7
Before we shutdown the alert execution threadpool, which caused us to use a hacky workaround to get the thread pool started again when alerts is going to run again.
Clearing the threadpool's queue is sufficient for stopping fired alerts from being ran. Only fired alerts already being executed by TP will won't be stopped.
Also removed the volatile previousFiredAlerts field, because execution the fired alert doesn't need the AlertService anymore the purpose of this field doesn't exist any more.
Original commit: elastic/x-pack-elasticsearch@6a622b5579
tableizing means evaluation is strictly linear time O(inputLength),
but costs #states * alphabet in ram. alphabet here is unicode (64k) so it blows up huge.
With tableize=false, it just means evaluation is O(inputLength * log(numIntervals)).
This is plenty fast for our purposes.
For these same reasons lucene only tableizes ByteRunAutomaton (alphabet size=256)
by default, for CharRunAutomaton it defaults to false.
Ban the trappy RunAutomaton ctor that tableizes. Fix tests using it.
Closeselastic/elasticsearch#739.
Original commit: elastic/x-pack-elasticsearch@28ab66b0ee
A large number of recent test failures have been caused by failure to bind
a port in the range 32900 to 32999. The ports are now tested to see if they
can be bound by this JVM and if not tries to bind another port. This will
decrease the likelihood of a port bind failure but another application could
still bind a port before the node starts up.
Closeselastic/elasticsearch#737
Original commit: elastic/x-pack-elasticsearch@aaf098758f
