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
This change removes these jars from shading and changes the assemblies file so that they are included as is.
Original commit: elastic/x-pack-elasticsearch@695f5e2b20
Also removed the version checking from the index template support, so that if the settings are changed these settings always get stored in the index template. This means we always put two index templates once watcher started.
And also shutdown watcher after the cluster service has been stopped.
This was done caused deadlock in the integration test framework when we are stopping the test cluster.
If multiple nodes are stopped, a node may briefly try to or run Watcher during the test cluster shutdown.
As part if starting we always put an index template, which will block any other start or stop calls for the WatcherService.
A node was running a put index template call as part of the start procedure while the start framework would stop the node.
The stop call would wait because it doesn't own the lock yet.
The put index template call didn't return, which caused the stop call the keep waiting.
The reason why put index template was hanging is that it failed to return anything while it the node was stopped.
Likely the put index template request got queued up waiting for a change in the cluster state, the cluster service
got stopped and the request got lost, but the watcher start procedure was still waiting.
By stopping Watcher before we stop the cluster service we avoid the scenario described above.
Original commit: elastic/x-pack-elasticsearch@db94b2279e
- wrote an intro where we tell how to get the watcher jar and we tall about the `WatcherClient`
- cleaned up the code snippets
- removed a reference to the `Watch.Parser`
- Also renamed `WatcherStatsResponse#getWatchServiceState` to `watcherStatsResponse.getWatcherState`
Original commit: elastic/x-pack-elasticsearch@814329cba7
An absraction aover XContent byte reference that:
- implements `ToXContent`
- can resolve values given a dot-notation path
- Used in `GetWatchResponse` and `ExecuteWatchResponse`
Also
- Moved `WatchExecutionResult` to the `execution` package
Original commit: elastic/x-pack-elasticsearch@0b41f53f38
- 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
Change them to consistently serialize themselves the same way they deserialize themselves.
If the script (or template) is read from a `string` value, it will serialize it self to xcontent as a `string` value as well. Otherwise it will serialize as an object, holding only those fields that where configured in the first place.
Original commit: elastic/x-pack-elasticsearch@52a82e0bbe
This change relocates the shaded jars for guava and owasp under org.elasticsearch.watcher.common and org.elasticsearch.watcher.common.owasp respectively.
Original commit: elastic/x-pack-elasticsearch@0e2d6303e0
This change moves the sanitization of the html body of emails to render time instead of at message send time.
Move the sanitization code the the EmailTemplate class.
Add <hr> tag to allowed html tags.
Add global setting `watcher.actions.email.sanitize_html` that defaults to true. If this is set to false html sanitization will be disabled
Add documentation for sanitization disable setting.
Enhance email tests to verify that sanitization is happening at construction time.
Fixeselastic/elasticsearch#356
Original commit: elastic/x-pack-elasticsearch@282a2d85c2
The body of the http input may hold xcontent data (json/yaml). The problem is that today, the body only accepts text and writing
escapted json in text makes it very hard to maintain.
This commit introduces another field settings - `xbody`. Now, use `xbody` for inlined xcontent and `body` for any text content. When `xbody` is used, we keep around the xcontent type and the http request that is then executed will include a content-type header that will match the xcontent type of input.
Original commit: elastic/x-pack-elasticsearch@7210908064
- added dynamic_templates to the index template that make sure not to analyze email addresses and http `path` and `host` under the `watch_execution` object. This will enabled building aggregations over these fields. Also make sure that different time fields in thw `watch_record` are mapped as date types.
- While at it changed the `watch_execution.input_result` mapping such that it's enabled and only disabled `watch_execution.input_result.payload` as different payloads from different sources may conflict with one another in terms of mappings
- Fixed a bug in the `EmailTemplate` building of the `reply_to` field.
- Also, added missing `execution_time` to the `watch_record` (under `watch_execution` object).
Closeselastic/elasticsearch#335
Original commit: elastic/x-pack-elasticsearch@dd28c70bca
The meta data field was known and `metadata` in the docs but the parsing logic expected `meta`.
This change unifies everything to use `metadata`. Also clean up Watch parsing to fail in a more consistent way when unknown fields are encountered.
Fixeselastic/elasticsearch#329
Original commit: elastic/x-pack-elasticsearch@a9013127d8
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
Also added assertions to verify if all watch record not null field are expected to be there at parse time.
Original commit: elastic/x-pack-elasticsearch@42052ae02c
The problem we have today is that since all write operations on a watch are blocked on the watch lock, if a watch is executing for a long time (for whatever reason) the action will simply block and by that hold a `management` thread for potentially a long time. This impacts elasticsearch as a whole - if for example there's an infinite loop in the condition script, then you try to delete/ack/update the watch 5 times (the default size of the management thread pool in elasticsearch is 5). You effectively block all management threads in elasticsearch and from that moment on, the only thing left to do is kill the node.
This commit introduces a timeout for the tree write watch actions - `put`, `ack` and `delete`. It is set to 10 seconds by default, but you can customize it both in java and in the rest API using the standard `master_timeout` query parameter.
Updated the relevant docs.
Fixeselastic/elasticsearch#309
Original commit: elastic/x-pack-elasticsearch@03292db37b
This change disallows the SCAN search type in our search requests used by search input and search transform.
Add tests for this and update the current tests to both detect SCAN and not use SCAN in valid tests.
Original commit: elastic/x-pack-elasticsearch@c9d61930c8