Batch Policy

The batch policy is designed to automatically group a large number of operations into smaller batches so that the service interruption can be better managed and there won’t be flood of service requests sending to any other services that will form a DOS (denial-of-service) attack.

Currently, this policy is applicable to clusters of all profile types and it is enforced when cluster is updated. The development team is still looking for an elegant solution that can regulate the resource creation requests.


Maximum number of nodes that will be updated in parallel.
Minimum number of nodes in service when performing updates.
Interval in seconds between update batches if any.


Below is a typical spec for a batch policy:

# Sample batch policy that can be attached to a cluster
type: senlin.policy.batch
version: 1.0
  # Minimum number of nodes that should remain in service when
  # performing actions like CLUSTER_UPDATE.
  min_in_service: 1

  # Maximum number of nodes that can be processed at the
  # same time.
  max_batch_size: 2

  # Number of seconds between two consecutive batches of
  # operations. A value of 0 means no pause time.
  pause_time: 3

The min_in_service property specifies the minimum number of nodes to be kept in ACTIVE status. This is mainly for cluster update use cases. The other property max_batch_size specifies the number of nodes to be updated in each batch. This property is mainly used to ensure that batch requests are still within the processing capability of a backend service.

Between each batch of service requests, you can specify an interval in the unit of seconds using the pause_time property. This can be used to ensure that updated nodes are fully active to provide services, for example.