Got it...and wait_for_batch_completion changes this from a "sliding" to a "rolling" window ?
On Mon, Oct 30, 2017 at 2:28 PM, Bill Farner <[email protected]> wrote: > Joshua beat me to the reply, so now you have corroboration for his > correction :-) > > On Mon, Oct 30, 2017 at 2:26 PM, Bill Farner <[email protected]> wrote: > >> Clarification - shard and instance are (unfortunately) used >> interchangeably in some of our docs, despite the fact that shard can have a >> different meaning in other contexts. >> >> The meaning of batch_size doesn't match either rephrasing you offer, >> perhaps the docs need work! batch_size effectively tells the updater what >> portion of your service may be down in the course of the update. This >> becomes the size of a sliding window as the update proceeds across the >> instances of the service. >> >> i.e. if batch_size is 3, the updater will start updating 3 instances >> immediately, and proceed through all instances with 3 instances updating a >> any time until it reaches the end. >> >> Does that clarify? >> >> On Mon, Oct 30, 2017 at 2:01 PM, Mohit Jaggi <[email protected]> >> wrote: >> >>> Folks, >>> Does the following doc mean A or B? >>> >>> *A*: batch_size is the number of instances in a given shard >>> *B:* batch_size is the number of shards. So every batch has (number of >>> instances)/(batch_size) tasks. >>> >>> Mohit. >>> UpdateConfig Objects >>> >>> Parameters for controlling the rate and policy of rolling updates. >>> objecttypedescription >>> batch_size Integer Maximum number of shards to be updated in one >>> iteration (Default: 1) >>> >> >> >
