...

Only a new user configuration  scaling-cooldown-period allowing the user to configure the minimum scaling time between 2 scaling operations

...

• If it falls outside a cooldown period, it is executed right away and a timer is started
• If it falls during the cooldown period, it is not dropped, it is rather stacked.queued
• Receiving a scaling event during a cooldown period does not reset the period timer to avoid  increasing the delay in scaling operations.
• When the period ends, all the stacked queued scaling operations are aggregated to result in into a single operation. This operation is executed and then a new scaling-cooldown-period is started

...

@startuml
!pragma teoz true 
skinparam ParticipantPadding 100
participant Scheduler as sch
participant ScalingOperationStackScalingOperationQueue as queue stack
participant CooldownTimer as timer
[-> sch : scaling event
sch -> sch : trigger scale change

{start1} sch -> timer : start timer

activate timer
[-> sch : scaling event
sch -> stackqueue : stackqueue operation
[-> sch : scaling event
sch -> stackqueue : stackqueue operation
{end1} timer --> sch : end of cooldown period  
deactivate timer
{start1} <-> {end1} : scaling-cooldown-period 
sch -> stackqueue : popdequeue operations
sch -> sch : aggregate operations
sch -> sch : trigger scale change
{start2} sch -> timer : start timer
activate timer
||120||
{end2} timer --> sch : end of cooldown period
deactivate timer

{start2} <-> {end2} : scaling-cooldown-period 

sch -> sch : no operation to trigger
@enduml

...

• A first scaling event is received and the scaling operation is executed right away leading to the creation of a cooldown period
• Then, 2 scaling events arrive during the  cooldown period. These events are stackedqueued.
• When the cooldown period ends, the stacked queued operations are aggregated and executed as a single scaling operation
• Executing this operation leads to creating another cooldown period. During this period no scaling event is received, so no new scaling operation is stacked queued 
• When this last cooldown period ends, the scheduler has finished his scaling job

...

But we could also consider that setting a default scaling-cooldown-period value to 300s would not break the user but rather give him a protection from against too frequent scale changes.

...

The new cooldown period feature should be covered by end-to-end tests. The current set of related end-to-end tests cover only resuming a pipeline with various configuration combinations (file/rocks, sync/async, parallelism change/ no parallelism change ...). So we need to add some E2E test cases covering the use cases described in the sequence diagram above measuring the time between scaling operations in various situations. We sould should be able to use the same DataStreamAllroundTestProgram in the E2E tests.

Rejected Alternatives

When scaling operations are popped from the stackdequeued, they are not executed one by once at a sclaing-cooldown-period pace to avoid adding too much delay in scaling.