Before this change DateTimes were being constructed without providing a time zone,
this was causing some non-utc time leakage. In particular watch record ids were being created with non utc dates and
watch records were going to the wrong .watch_history index.
Add Clock.now(DateTimeZone) to allow callers to get UTC now.
Also construct the DateTimes with UTC timezones when we construct from millis.
Add all constuctors of DateTime that do not specify a time zone to the forbidden APIs.
This change makes constructing a `DateTime` object without providing a `DateTimeZone` forbidden.
This is much safer and makes time zone errors much more unlikely to occur.
Statically import DateTimeZone.UTC everywhere it was being used
Now all calls that use DateTimeZone.UTC just refrence UTC.
Fixeselastic/elasticsearch#150
Original commit: elastic/x-pack-elasticsearch@7f23ce605e
Mainly how templates read/write themselves from/to xcontent. Instead of using `text`, use `template`
Original commit: elastic/x-pack-elasticsearch@0d6f317539
* Split the transform into two constructs: `Transform` and `ExecutableTransform`. The former holds all the transform configuration, the latter can execute the transform based on that configuration (an executable transform holds a transform)
- This makes the code clearer to understand and maintain.
- This also enabled to pull some common implementation code into the `ExecutableTransform` and by that reduce the implementation details of each executable to the minimum required.
* Also, extracted the `Transform.Parser` to its own top level class, and renamed it to - `TransformFactory`. The main thing that the factory does is: 1) delegate to the parsing to the `Transform` class, 2) construct & wire up the `ExecutableTransform`.
* With the introduction of `Transform`, we no longer need the `SourceBuilder` for transforms. Instead, we have `Transform.Builder` that help you build a transform. This is much more intuitive from the client perspective.
Original commit: elastic/x-pack-elasticsearch@f6ee0d0c75
* Tune the index templates for higher index throughput.
* Trigger events should be processed and indexed in an async manner.
* Moved the job name into the TriggerEvent
* Added support for fire multiple events at the same time. If multiple events are fired at the same time then use async bulk to persist the watch record.
* Cut simple ticker and timer ticker over to fire multiple events at the same time
* Don't fire more than 1000 events at the time. (this also may result in large bulk requests)
Original commit: elastic/x-pack-elasticsearch@c7f6bd3812
* Changed the isolated ScheduleEngineBenchmark to tests all engines and collect statistics during a test run.
* Updated the isolated schedule benchmark to just test the trigger part of the scheduler and capture some basic matrics.
Original commit: elastic/x-pack-elasticsearch@88bbf3688d
- `TimerScheduleTriggerEngine` - a single threaded Java `Timer`based scheduler. "Ticks" every second and checks all the registered schedules.
- `SimpleTickerScheduleTriggerEngine` - a single threaded scheduler. "Ticks" every second and checks all the registered schedules
- `SchedulerScheduleTriggerEngine` - a single threaded engine based on Java's schedule executor service. Here, every job is added as a scheduled task to the executor and each job is managing its own execution times.
- `HashWheelScheduleTriggerEngine` - a single threaded engine based on Netty's `HashWheelTimer`. Like with the `scheduler` above, every job is added as a scheduled task to the executor and each job is managing its own execution times.
Also:
- Added an undocumented feature to configure the schedule engine in the settings using `watcher.trigger.schedule.engine` (optional values right now are `quartz`, `simple`, `timer`, `hashwheel` and `scheduler`)
- `Cron` is a fork/copy of quartz `CronExpression`.. a bit cleaned up though.
- `Schedule` now exposes `nextScheduledTimeAfter` to return the next scheduled time after the given one.
- `CronnableSchedule` is now based on `Cron` (this exposed bugs in the schedule tests where we generated invalid cron expression. Now, since `Cronnable` creates the actual cron, validation is in place to make sure only valid expressions are created)
- While at it... refactored how the thread pool settings are set. Removed it from the plugin class, now each module is responsible for the settings of its own TPs. Also, if the thread pools are already configured in node settings we don't configure our default ones. This will enable users to configure the TPs in `elasticsearch.yml`
- Also updated `CronEvalTool` to work with `DateTime` construct (instead of java's `Date`)
Original commit: elastic/x-pack-elasticsearch@40d107c66e
* 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
The default mustache template that is supported by elasticsearch doesn't support array/list access. This poses a real limitation for watcher as with `search` input, the hits are returned as an array/list. To bypass this limitation, an extra (tedious) step is required in order to transform the hits to a data structure that is supported by mustache.
This commit adds a new mustache script engine - `xmustache` to elasticsearch that supports array/list access in the form of `array.X` where `X` is the index into the array/list. This enables accessing the search results without using a transform. The following example will fetch the `"key"` field of the 3rd hit in the search result: `ctx.payload.hits.hits.3._source.key`.
This array/list support will be added to elasticsearch, but it'll only be available in later versions. For now, the default template in watcher will therefore be `xmustache`.
Added docs for templates
Fixeselastic/elasticsearch#230
Original commit: elastic/x-pack-elasticsearch@b09cad7f8b
The watch metadata is now accessible to the templates and scripts (under `ctx.metadata`).
Also, changed the default email attachment to include the ctx model as a whole (not just the payload). This provides more context to the watch exectuion (e.g. watch id, execution time, metadata, etc...)
Original commit: elastic/x-pack-elasticsearch@c5dde855d2
The `WatchLockService` was not using fair locks. This could result in out of order execution of queue executions of the same watch.
Fork KeydLock tests from core and make global lock fair.
Fixeselastic/elasticsearch#225
Original commit: elastic/x-pack-elasticsearch@77382e09ca
This changes the SignatureService into a CryptoService that now supports encryption
operations in addition to the signing operations. The encryption leverages the existing
system key and uses it with AES.
Closeselastic/elasticsearch#805
Original commit: elastic/x-pack-elasticsearch@a792ed4a54
For the CLI tools in Shield we create a new temp file and replace the existing file
to prevent issues with reloading a half written file. This has a potential side effect
of changing the user and group that own the file. Many times the commands are
run with root privileges (sudo) and when run with root privileges we can actually
reset the owner and group correctly.
Closeselastic/elasticsearch#812
Original commit: elastic/x-pack-elasticsearch@1ee3715376
* Split the action into two constructs: `Condition` and `ExecutableCondition`. The former holds all the condition configuration, the latter can execute the condition based on that configuration (an executable condition holds a condition)
- This the code clearer to understand and maintain.
- This also enabled to pull some common implementation code into the `ExecutableCondition` and by that reduce the implementation details of each executable to the minimum required.
* Also, extracted the `Condition.Parser` to its own top level class, and renamed it to - `ConditionFactory`. The main thing that the factory does is: 1) delegate to the parsing to the `Condition` class, 2) construct & wire up the `ExecutableCondition`.
* With the introduction of `Condition`, we no longer need the `SourceBuilder` for conditions. Instead, we have `Condiiton.Builder` that help you build condition. This is much more intuitive from the client perspective.
* Renamed `always_true` condition type to `always`
* Renamed `always_false` condition type to `never`
* Updated docs (also added docs for the `never` condition)
Original commit: elastic/x-pack-elasticsearch@0f8eb494ca
We weren't properly registering the chain or script transforms so that they were accessable from the Watch.parse and PUT Watch APIs.
Original commit: elastic/x-pack-elasticsearch@2a236d62f3
This change makes the default throttle period 5s.
This default can be controlled from config with the parameter `watcher.throttle.period.default_period`.
Added test and updated docs.
Original commit: elastic/x-pack-elasticsearch@cf8f5de724
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
There were a few corner cases where a `HistoryStore.put` operation was underway while we were shutting down since we were not holding any lock during this time.
This change adds a ReadWriteLock and uses the ReadLock for updates and put operations and the WriteLock for shutdown.
Also add a lock around the manual execution of a watch since it could change the status.
Fixeselastic/elasticsearch#204
Original commit: elastic/x-pack-elasticsearch@60ef78eff5
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
For HMAC and password hash comparisons we need to use a time
constant comparison that always compares the whole value in order
to protect against timing attacks.
Original commit: elastic/x-pack-elasticsearch@f6082c76b9
something seems to be broken... either in the integration test infra or somewhere else.. .investigation required
Original commit: elastic/x-pack-elasticsearch@c27bc41ef4
Brian Murphy
Martijn van Groningen
uboness
jaymode
Bill Hwang