If we failed to parse a `Watch` or `WatchRecord` at startup we currently get stuck as this behaviour is undefined.
This commit just adds some logging so we can tell that this is what happened.
Original commit: elastic/x-pack-elasticsearch@aa6d95c172
* Split the action into two constructs: `Action` and `ExecutableAction`. The former holds all the action configuration, the latter can execute the action based on that configuration (an executable action holds an action)
- This the code clearer to understand and maintain.
- This also enabled to pull some common implementation code into the `ExecutableAction` and by that reduce the implementation details of each executable to the minimum required.
* Also, extracted teh `Action.Parser` to its own top level class, and renamed it to - `ActionFactory`. The main thing that the parser does is: 1) delegate to the parsing to the `Action` class, 2) construct & wire up the `ExecutableAction`.
* Cleaned up and aligned the log messages across all actions. Introduced
- introduced parameterized exceptions (now the exception messages are constructed exactly like that log messages - using `{}` params)
- Introduced the notion of `Wid` - Watch (execution) ID`. Now the `WatchExecutionContext` and the `WatchRecord` hold this construct as their ID (instead of an opaque string). The Wid has a well defined structure where it's prefixed with the watch id. This is very helpful to provide context to parsing the different constructs (actions in our case) as when parsing error occurs we can point directly to the place were we found the error (ie. watch id, record id and action id).
* With the introduction of `Action`, we no longer need the `SourceBuilder` for actions. Instead, we have `Action.Builder` that help you build actions. This is much more intuitive from the client perspective.
Original commit: elastic/x-pack-elasticsearch@df22da4e1f
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
`
{
"script" : "<script>"
}
`
Should be a valid script condition. This was silently failing to parse creating invalid watches in the system that could not be executed or interacted with except via DELETE.
Added a test for this as well.
Fixeselastic/elasticsearch#191
Original commit: elastic/x-pack-elasticsearch@25ed27bf2e
- Introduced `TemplateEngine` and its only implementation `MustacheTemplateEngine`
- Change `Template` to only hold the template config.. the rendering is now done by the engine
- Introduced `EmailTemplate` that can render itself to an `Email` (given an engine and model)
- Renamed `TemplatedHttpRequest` to `HttpRequestTemplate` and it has a `render` method that given a model and an engine it creates an `HttpRequest` construct.
- also fixed a bug where when the http request is build, the configured scheme wasn't set.
- cleaned up `HttpRequest` - made it immutable and now we use a builder to build it.
- also fixed a bug in `HttpRequest` where the xcontent didn't render the scheme
- Got rid of all old template implementations... also, parsing a template is now simply `Template.parse(...)` (no need for a special `TemplateParser`.
- While at it, change the action builder to only deal with actions and not know anything about the action id. The id is now passed to the watch builder directly when adding an action
Original commit: elastic/x-pack-elasticsearch@1a7acc5868
- 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
something seems to be broken... either in the integration test infra or somewhere else.. .investigation required
Original commit: elastic/x-pack-elasticsearch@c27bc41ef4
- Added watch CRUD tests + cleanup
- Changed and aligned terminology across the board. No more "watch name".. from now on we'll refer to it as "watch id" (aligned with the public APIs). Also the templates now refer to `"{{ctx.watch_id}}"` (instead of `"{{ctx.watch_name}}"`)
- cleaned up the Response constructs (removed dependency on index/delete/get responses)
Fixeselastic/elasticsearch#202
Original commit: elastic/x-pack-elasticsearch@3296a69128
Super useful when dealing with the `cron` schedule. It enables to:
1. validate a cron expression. If the cron expression is incorrect it will try to output a descriptive/guiding error message
2. show future times in which the cron expression will be triggered (based on the current time)
When deployed, once can access this tool from ES_HOME by `bin/watcher/croneval`
Also updated the docs
Original commit: elastic/x-pack-elasticsearch@2666c32a69
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
- When the license is disabled, all actions of all watches are throttled, and all watcher APIs are blocked.
- before license expiry we're logging warning messages to the standard log file.
- Added a check on startup verifying the installed license plugin confirms to the min compatibility requirement of watcher
- Added a check on startup verifying the installed shield plugin (if one is installed) confirms to the min compatibility requirement of watcher
- Fixed a bug in simple input deserialization where it expected a `payload` field that should be there.
- Fixed a bug in `WatcherServiceResponse` where the acknowledged state wasn't de/serialized
Closeselastic/elasticsearch#30
Original commit: elastic/x-pack-elasticsearch@35dcaf4feb
Mainly useful for testing & debugging, but might be even useful as an actual action in production.
(for now, we won't document it)
Original commit: elastic/x-pack-elasticsearch@726049cece
- actions are not identified by a unique id. The actions in a "watch" definition are now keyed (instead of an array)
- the `ActionWrapper` is now a construct that holds: and action, the id of the action and optionally a transform
- the `webhook` action is now structured based on the templated http request it holds (no need for extra `request` element there`
- the `webhook` reponse holds the http response (not the `status` and `body` directly)
- the action builders now accept an `id` when created
- introduced `WatchSourceBuilders` for quickly access various source builders
- introduced `Template.SourceBuilder` to help building a template
- changed templated http request builder to accept template source builders (instead of templates directly)
- changed `HttpResponse` to accept the body as a `ByteReference` in the ctor (this construct used to be in an inconsistent state holding an input stream that could have already been read)
Original commit: elastic/x-pack-elasticsearch@296350b6a8
- now enables defining `types` (for document types)
- enables defining `types` and `indices` as comma-delimited strings (not just string arrays)
- aligned the parsing in `WatcherUtils` with the way we're parsing xcontent across the board (e.g. using `ParseField`)
- Added additional unit test to test deserialization
Original commit: elastic/x-pack-elasticsearch@5491b85f75
This commit enables the script transform return any value. If the value is of type `Map` we'll just use it as the payload itself. Otherwise (any other value type) we'll take that value and put it in a map under the `"_value"` key, and that map will be the new payload.
This will simplify writing scripts (as it doesn't require the script to build a map)
Original commit: elastic/x-pack-elasticsearch@73fab7dc2b
This commit fixes two issues.
1. The actual emails that were being sent after getting the defaults applied were not being returned as part of EmailSent
2. There was a possible NPE when writing an `Email` if from or to was null.
Closeselastic/elasticsearch#147
Original commit: elastic/x-pack-elasticsearch@0468280090
This commit adds tests for the webhook and index actions.
Also adds docs for the webhook and index actions and fixes url escaping of webhook action urls.
Original commit: elastic/x-pack-elasticsearch@b70435b198
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
The http input allows to let any http interface be the input for a watch.
The http input can be configured with the following options:
* `method` - Optional http method. (default to GET)
* `host` - The host of the http service.
* `port` - The port of the http service.
* `path` - The url path.
* `params` - Optional url query string options.
* `header` - Optional http header.
* `auth` - Optional authentication http heads.
* `body` - Optional body
The response of the http request is expected to be valid json.
Closeselastic/elasticsearch#157
Original commit: elastic/x-pack-elasticsearch@0b1f122615
Brian Murphy
Martijn van Groningen
uboness
Bill Hwang