anchor.diff:  `properties`:: (map, optional) Any additional properties. Currently includes e.g., `nodeNames` property that
   indicates the nodes that were lost or added.
   
  -== Node Added Trigger
  +== Trigger Configuration
  +Trigger configurations are managed using the <<solrcloud-autoscaling-api.adoc#write-api,Autoscaling Write API>> with the commands `<<solrcloud-autoscaling-api.adoc#create-update-trigger,set-trigger>>`, `<<solrcloud-autoscaling-api.adoc#remove-trigger,remove-trigger>>`,
  +`suspend-trigger`, and `resume-trigger`.
  +
  +=== Trigger Properties
  +
  +Trigger configuration consists of the following properties:
  +
  +`name`:: (string, required) A unique trigger configuration name.
  +
  +`event`:: (string, required) One of the predefined event types (`nodeAdded` or `nodeLost`).
  +
  +`actions`:: (list of action configs, optional) An ordered list of actions to execute when event is fired.
  +
  +`waitFor`:: (string, optional) The time to wait between generating new events, as an integer number immediately
  +followed by unit symbol, one of `s` (seconds), `m` (minutes), or `h` (hours). Default is `0s`. A condition must
  +persist at least for the `waitFor` period to generate an event.
  +
  +`enabled`:: (boolean, optional) When `true` the trigger is enabled. Default is `true`.
  +
  +Additional implementation-specific properties may be provided, as described in the sections for individual triggers below.
  +
  +=== Action Properties
  +
  +Action configuration consists of the following properties:
  +
  +`name`:: (string, required) A unique name of the action configuration.
  +
  +`class`:: (string, required) The action implementation class.
  +
  +Additional implementation-specific properties may be provided, as described in the sections for individual triggers below.
  +
  +If the `actions` configuration is omitted, then by default, the `ComputePlanAction` and the `ExecutePlanAction` are automatically added to the trigger configuration.
  +
  +=== Example Trigger Configuration
  +
  +This simple example shows the configuration for adding (or updating) a trigger for `nodeAdded` events.
  +
  +[source,json]
  +----
  +{
  + "set-trigger": {
  +  "name" : "node_added_trigger",
  +  "event" : "nodeAdded",
  +  "waitFor" : "1s",
  +  "enabled" : true,
  +  "actions" : [
  +   {
  +    "name" : "compute_plan",
  +    "class": "solr.ComputePlanAction"
  +   },
  +   {
  +    "name" : "custom_action",
  +    "class": "com.example.CustomAction"
  +   },
  +   {
  +    "name" : "execute_plan",
  +    "class": "solr.ExecutePlanAction"
  +   }
  +  ]
  + }
  +}
  +----
  +
  +This trigger configuration will compute and execute a plan to allocate the resources available on the new node. A custom action could also be used to possibly modify the plan.
  +
  +== Available Triggers
  +
  +As described earlier, there are several triggers available to watch for events.
  +
  +=== Node Added Trigger
   
   The `NodeAddedTrigger` generates `nodeAdded` events when a node joins the cluster. It can be used to either move replicas
   from other nodes to the new node or to add new replicas.
   
  -Apart from the parameters described at <<#trigger-configuration, Trigger Configuration>>, this trigger supports the following configuration:
  +In addition to the parameters described at <<Trigger Configuration>>, this trigger supports one more parameter:
   
   `preferredOperation`:: (string, optional, defaults to `movereplica`) The operation to be performed in response to an event generated by this trigger. By default, replicas will be moved from other nodes to the added node. The only other supported value is `addreplica` which adds more replicas of the existing collections on the new node.
   
  
positive.code: 
  This trigger applies the `every` date math expression on the `startTime` or the last event time to derive the next scheduled time and if current time is greater than next scheduled time but within `graceTime` then an event is generated.
  
  Apart from the common event properties described in the Event Types section, the trigger adds an additional `actualEventTime` event property which has the actual event time as opposed to the scheduled time.
  
  For example, if the scheduled time was `2018-01-31T15:30:00Z` and grace time was `+15MINUTES` then an event may be fired at `2018-01-31T15:45:00Z`. Such an event will have `eventTime` as `2018-01-31T15:30:00Z`, the scheduled time, but the `actualEventTime` property will have a value of `2018-01-31T15:45:00Z`, the actual time.
  
  == Trigger Configuration
  Trigger configurations are managed using the Autoscaling Write API and the commands `set-trigger`, `remove-trigger`,
  `suspend-trigger`, and `resume-trigger`.
  
  Trigger configuration consists of the following properties:
  
  `name`:: (string, required) A unique trigger configuration name.
  
  `event`:: (string, required) One of the predefined event types (`nodeAdded` or `nodeLost`).
  
  `actions`:: (list of action configs, optional) An ordered list of actions to execute when event is fired.
  
  `waitFor`:: (string, optional) The time to wait between generating new events, as an integer number immediately
  followed by unit symbol, one of `s` (seconds), `m` (minutes), or `h` (hours). Default is `0s`. A condition must
  persist at least for the `waitFor` period to generate an event.
  
  `enabled`:: (boolean, optional) When `true` the trigger is enabled. Default is `true`.
  
  Additional implementation-specific properties may be provided.
  
  Action configuration consists of the following properties:
  
  `name`:: (string, required) A unique name of the action configuration.
  
  `class`:: (string, required) The action implementation class.
  
  Additional implementation-specific properties may be provided
  
  If the `actions` configuration is omitted, then by default, the `ComputePlanAction` and the `ExecutePlanAction` are automatically added to the trigger configuration.
  
  .Example: adding or updating a trigger for `nodeAdded` events
  [source,json]
  ----
  {
   "set-trigger": {
    "name" : "node_added_trigger",
    "event" : "nodeAdded",
    "waitFor" : "1s",
    "enabled" : true,
    "actions" : [
     {
      "name" : "compute_plan",
      "class": "solr.ComputePlanAction"
     },
     {
      "name" : "custom_action",
      "class": "com.example.CustomAction"
     },
     {
      "name" : "execute_plan",
      "class": "solr.ExecutePlanAction"
     }
    ]
   }
  }
  ----
  
  This trigger configuration will compute and execute a plan to allocate the resources available on the new node. A custom action is also used to possibly modify the plan.
  
negative.code: // specific language governing permissions and limitations
  // under the License.
  
  Triggers are used in autoscaling to watch for cluster events such as nodes joining or leaving, search rate, index rate, on a schedule, or any other metric breaching a threshold.
  
  Trigger implementations verify the state of resources that they monitor. When they detect a
  change that merits attention they generate _events_, which are then queued and processed by configured
  `TriggerAction` implementations. This usually involves computing and executing a plan to do something (e.g., move replicas). Solr provides predefined implementations of triggers for <<Event Types,specific event types>>.
  
  Triggers execute on the node that runs `Overseer`. They are scheduled to run periodically, at a default interval of 1 second between each execution (although it's important to note that not every execution of a trigger produces events).
  
  == Event Types
  Currently the following event types (and corresponding trigger implementations) are defined:
  
  * `nodeAdded`: generated when a node joins the cluster. See <<Node Added Trigger>>.
  * `nodeLost`: generated when a node leaves the cluster. See <<Node Lost Trigger>> and <<Auto Add Replicas Trigger>>.
  * `metric`: generated when the configured metric crosses a configured lower or upper threshold value. See <<Metric Trigger>>.
  * `indexSize`: generated when a shard size (defined as index size in bytes or number of documents)
  exceeds upper or lower threshold values. See <<Index Size Trigger>>.
  * `searchRate`: generated when the search rate exceeds configured upper or lower thresholds. See <<Search Rate Trigger>>.
  * `scheduled`: generated according to a scheduled time period such as every 24 hours, etc. See <<Scheduled Trigger>>.
  
  Events are not necessarily generated immediately after the corresponding state change occurred; the
  maximum rate of events is controlled by the `waitFor` configuration parameter (see <<Trigger Configuration>> below for more explanation).
  
  The following properties are common to all event types:
  
  