Re: updateconfig doc

[Bill Farner]

Correct!

On Mon, Oct 30, 2017 at 2:32 PM, Mohit Jaggi  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  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  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 
>>> 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)

>>>
>>>
>>
>

Re: updateconfig doc

[Mohit Jaggi]

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  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  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 
>> 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)
>>>
>>
>>
>

Re: updateconfig doc

[Bill Farner]

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  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  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)
>>
>
>

Re: updateconfig doc

[Bill Farner]

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  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)
>

Re: updateconfig doc

[Joshua Cohen]

It's C: batch_size is the number of instances that can be updated at a
given time.

There's no direct relation between batch size and total number of
shards/instances. E.g. for a job with 100 instances and a batch size of 10,
at most 10 instances will be updating at a given time. If it turns out that
all instances finish updating at exactly the same time, then it would take
10 batches to complete the update. However, the more likely scenario is
that due to scheduling delays, startup times, etc., updates from the
initial batch will complete at staggered intervals. As individual instances
complete their update, additional instances will begin their updates to
keep the number of instances currently updating at batch_size.

Does that make sense?

On Mon, Oct 30, 2017 at 4:01 PM, Mohit Jaggi  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)
>