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.
Below is a typical spec for a batch policy:
# Sample batch policy that can be attached to a cluster
# Minimum number of nodes that should remain in service when
# performing actions like CLUSTER_UPDATE.
# Maximum number of nodes that can be processed at the
# same time.
# Number of seconds between two consecutive batches of
# operations. A value of 0 means no pause time.
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
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.