Correct! On Mon, Oct 30, 2017 at 2:32 PM, Mohit Jaggi <[email protected]> wrote:
> 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) >>>> >>> >>> >> >
