- Renamed `watch_execution` to `execution_result`
- Renamed `actions_results` to `actions`
- Renamed `input_result` to `input`
- Renamed `condition_result` to `condition`
- Updated the `watch_history.json` template to reflect the changes, also added concrete mappings for action types (such that field that should not be analized will be mapped as `not_analyzed`
- Fixed a bug in `WatchUtils.createSearchRequestFromPrototype` where the document types were ignored.
Also, changed the `actions` (fka `actions_results`) from an object to an array. the action id is not part of the action objects (indicated by the `id` field). For example:
```
{
"actions" : [
{
"id" : "my_email",
"email" : {
...
}
}
]
}
```
The reason for this change is to make the path to the action fields predictable deterministic. With the object structure, where the actions were keyed by their `id`, the path to the action fields depended on the action id, which is unpredictable and continuously changing from one action to another. This made it impossible to properly analyze the action data using aggregations (as aggs require full path into the aggregated fields).
With this change, the mappings of `watch_record` changed as well where the `actions` are not defined as nested type, yet it is still configured to include all the fields in the root object. We do this so in the future, when appropriate support will be added to kibana, it'll be able to apply nested aggregations on the actions, enabling correct/safe multi-dimensional aggregations. In the mean time however, while kibana doesn't support nested aggregations, we still need to have all the fields indexed on the root, so at least a single dimensional aggregations can be safely applied.
Also, change the `input` and `condition` objects in the `watch_record` such that their mappings are disabled. The main reason for this is the fact that a lot of the inputs use elements that can be configured in many ways, but the mappings are too strict to accept it. For example, a template can be configured as a `string` or as an `object`.
Original commit: elastic/x-pack-elasticsearch@83464a0c71
This change adds a force paramter to delete to allow the forcing of a delete to happen ignoring locking.
This means that watch executions may fail when they go to update the watch. Watches executing from the scheduler will fail fast if the watch they are supposed to execute has been removed.
Also move the history store updates outside of the watch locks.
Fixes: elastic/elasticsearch#405
Original commit: elastic/x-pack-elasticsearch@57561b6f85
Some of the non java clients don't return the body on an ignore: 404 so we must use catch missing instead.
Original commit: elastic/x-pack-elasticsearch@a10582691c
Scripts and Templates are very much alike. There are only two main differences between them when it comes to watcher:
1. The template doesn't have a language type - it's always mustache.
2. Templates are often used to render xcontent (json/yaml). So there's build in support for content type in it
Traditionally, in es core, the configuration of the scripts and templates was always a bit of a mess. There was no consistency between the two and when it comes to the templates configuration, they're even not future proof (future additions to the search requests body can break the templates).
After a long discussion, we've decided that we need to change the way users configure templates & scripts in es core... and align the two. These changes will only come in es 2.0. That said, it's important that watcher will be aligned with es core in how templates and scripts are configured and therefore we need to change it for that purpose.
Watcher will come with support for the scripts & templates configuration format of es 2.0. We want to future proof the configuration from day one.
here are the configuration:
Inline:
```
{
"inline" : "script here",
"lang" : "lang here",
"params" : { parameters here }
}
```
File:
```
{
"file" : "file name here",
"lang" : "language here",
"params" : { parameters here }
}
```
Indexed:
```
{
"id" : "template id here",
"lang" : "language here",
"params" : { parameters here }
}
```
For templates it's the same configuration except there is no `lang` field. Also, for templates, there's native support for xcontent:
```
{
"inline" : { "key" : "{{param1}}" },
"params" : { "param1" : "value1" }
}
}
```
Original commit: elastic/x-pack-elasticsearch@4a31114f35
This change adds the parameter `master_timeout` to the rest requests that can write to a watch PUT, ACK and DELETE.
Also add support in the rest tests to verify that this is accepted.
Fixes: elastic/elasticsearch#416
Original commit: elastic/x-pack-elasticsearch@4cc1c50f2c
This change renames the hijack test name from "Test Hijack api" to "Test Hijack and Block Direct Access to Internal Indices".
Original commit: elastic/x-pack-elasticsearch@118ac18132
This change changes the manual trigger event to be a wrapper for another `TriggerEvent`.
TriggerEvent is required field for the execute API either via setTriggerEvent on the request or requestBuilder in the java API or `trigger_event` in the REST API
Original commit: elastic/x-pack-elasticsearch@790bdb96a5
- Moved it to its own top level enum `WatcherState`
- Also changed the key holding the current state in the `stats` API to `watcher_state`
Original commit: elastic/x-pack-elasticsearch@2e5ca90f57
This change hijacks the document APIs for the .watches index and prevents direct access to these APIs via REST.
This hijacking is controlled by the "watcher.index.rest.direct_access" setting, this setting defaults to false which restricts access to the index. To allow direct access to the .watches index from the REST API set this setting to `true`
Copied json files from core es to test this feature and added comments to the json files indicating why they have been copied from es core.
Fixeselastic/elasticsearch#336
Original commit: elastic/x-pack-elasticsearch@22335750bd
This change changes the watch specific actions put/get/delete/execute/ack to be watcher.<action>_watch.
Original commit: elastic/x-pack-elasticsearch@86a91cb141
SearchInput using inline, indexed and on disk templates.
ScriptedCondition where the script accesses the ctx.
ScriptedCondition where the script throws an exception.
ScriptedCondition where the script doesn't return a boolean.
Webhook tests using templated body, path and parameters.
Some REST test fixes.
Original commit: elastic/x-pack-elasticsearch@d02b6d1d7b
* Split the action into two constructs: `Input` and `ExecutableInput`. The former holds all the input configuration, the latter can execute the input based on that configuration (an executable input holds an input)
- This the code clearer to understand and maintain.
- This also enabled to pull some common implementation code into the `ExecutableInput` and by that reduce the implementation details of each executable to the minimum required.
* Also, extracted the `Input.Parser` to its own top level class, and renamed it to - `InputFactory`. The main thing that the factory does is: 1) delegate to the parsing to the `Input` class, 2) construct & wire up the `ExecutableInput`.
* With the introduction of `Input`, we no longer need the `SourceBuilder` for inputs. Instead, we have an `Input.Builder` that help you build an input. This is much more intuitive from the client perspective.
* Changed the `request` xcontent field in the http input result to `sent_request` for clarity
* Changed the `request` xcontent field in the search input result to `executed_request` for clarity
Original commit: elastic/x-pack-elasticsearch@63b93f9c7b
This change persists the Watch.Status if needed by marking the Status as `dirty` if the status mutates during watch execution.
If the status is dirty it will be persisted at the end of execution while the execution lock is held.
Change record_in_history to record_execution which also controls weither the status will be updated.
Fixeselastic/elasticsearch#222
Original commit: elastic/x-pack-elasticsearch@25869cabf0
This change adds a new test class that runs the REST tests with the license disabled.
It checks the error message to make sure that all api access is blocked from all the apis we normally test.
Fixeselastic/elasticsearch#193
Original commit: elastic/x-pack-elasticsearch@a70de9b7a7
- What used to be the `HistoryService` is not named `ExecutionService`. In fact, it always was an execution context and was simply named wrong and place in the wrog place in the code.
- A new `execution` package was created, to contain all execution related contsructs which includes the new `ExecutionService`, `WatchExecutionContext`, `WatchExecutor`, `InternalWatchExecutor`.
- The `WatchExecutionContext` role in the execution process was extended to also enable it to "control" the execution. "control" in the sence that it can now provide default results to some of the contructs (for example, it can provide a default input and by that skip the execution of the input). Also, it enables simulating actions (more bellow).
- There are two implementations now of the `WatchExecutionContext`. A `TriggeredExecutionContext` which is used when the trigger service triggers the execution of a watch. And `ManualExecutionContext` enabling to manually execute a watch. The latter, can be configured such that different phases in the normal executions of the watch can be skipped. This is great for simulating a watch execution, that is, executing a watch without actually fully executing the actions (e.g. create the emails that the email action would have normally send, but without actually sending it). Both of these new context implementations also sit in the new `execution` package.
- With the changes described above, the actions now consult the execution context before actually performing their tasks. If the execution context indicates that the action should run in a "simulated" mode, the action will semi execute and return a `Simulated` result. Each action type defines what is "simulated mode" for it. For example, the email action creates the email and renders all its templats but doesn't actually send it, the returned `Email.Simulated` result will contain the email that would have been sent if it was running under normal conditions (non-simulated mode). The `index` action, doesn't actually indexes anything (just creating the index request that would have been executed), and the `webhook` action only creates the HTTP request but doesn't actually send it.
- A new `execute` API was introduced that utilizes all of the above and enables to manually execute registered watches. The API provides all the tools to control what actions are simulated and enables skipping the execution of the watch `input` and `condition`. By default it also skip the recording of the execution in the watch history (though this can be enabled if desired). This API is exposed both by the Java `WatcherClient` and via a dedicated REST endpoint. (documentation around this new API was added as well)
Closeselastic/elasticsearch#149
Original commit: elastic/x-pack-elasticsearch@ee8fe0490a
This change adds support for testing all watcher REST endpoints.
It also updates the api docs to be current with the latest code.
Change GetWatchResponse to only have the information in needs
GetWatchResponse used to contain a GetResponse this is not needed. Now it just contains the needed fields.
Closeselastic/elasticsearch#35
Original commit: elastic/x-pack-elasticsearch@905c5da318
This commit adds support for rest tests using the same yaml and json formatting as for core elasticsearch.
Also added is support for shield in the rest tests.
Original commit: elastic/x-pack-elasticsearch@bbeb9c0fc9
uboness
Brian Murphy
Clinton Gormley
Honza Král