There is this TODO comment in the scale_handler.go, I wonder whether it is still relevant:
@TsuyoshiUshio can you please take a look and let me know if you have any questions?
Hi @zroubalik and @ahmelsayed
Sorry, I forget to implement the push scaler case. The reason the comment is there is, You can see the hard corded value. It is scaleTo and MaxScale. I need to write one more method on scale_handler.go.
I have a question. For the startPushScaler method, why it calls RequestScale method for each loop? For the scaling, there are several scaler exists at the same time, that is why scale logic is calculated from all scalers metrics. So that checkScalers passing scalars array to the RequestScale. https://github.com/kedacore/keda/blob/v2/pkg/scaling/scale_handler.go#L181
However, startPushScalers method looping with go routine. for each go routine request scale in parallel. That means, if the 2 push scaler is there, then it is going to exceed the maxscale. https://github.com/kedacore/keda/blob/v2/pkg/scaling/scale_handler.go#L142 What I'd like to know is, why do you change de design between checkScalers and startPushScalers. I'd like to know the context and background.
The behavior of a push scaler is to push isActive state whenever there is an external event. Multiple push scalers don't have to coordinate that push with each other because they are not pushing a particular number to scale to, but rather just the isActive state. if multiple scalers push isActive at the same time, KEDA will only attempt to activate the deployment (scale to 1) for the first and debounces the rest. How does scaledJob handles multiple triggers reporting isActive on every pollingInterval. You can think of push scalers as if the pollingInterval is 0.
Thank you @ahmelsayed Then for the scaled job for the Push Scaler, can I assume something like this? I can't understand the meaning of the debounces. Is it only the first one is executed? If I assume so,
Sorry for the basic question, could you tell me some usecase for Scaled Job with Push Scaler?
Thank you @ahmelsayed to share the info with me offline.
I noticed that ScaledJob doesn't fit for the current implementation for using the go routine.
https://github.com/kedacore/keda/blob/b6c60a088a7ac5683638feba3692b40b0b613f29/pkg/scaling/scale_handler.go#L168
PushScaler could be more than 1,
My suggestion is,
startPushScaler method is called, if the object is scaled jobs, Loop through the PushScalers. (not to loop on the current go routine)scaleTo by the scaler's metadata by the all PushScalers metadata so that if there is multiple push scalers were there, the amount of the job doesn't exceed the MaxScale.It is similar to the current implementation of the ScaledJob for non-Push scalers.
If it is ok, I'll implement it and find time to do it.
That sounds good to me.
I think this issue ok for now.
Most helpful comment
Thank you @ahmelsayed to share the info with me offline.
I noticed that ScaledJob doesn't fit for the current implementation for using the go routine.
https://github.com/kedacore/keda/blob/b6c60a088a7ac5683638feba3692b40b0b613f29/pkg/scaling/scale_handler.go#L168
PushScaler could be more than 1,
My suggestion is,
startPushScalermethod is called, if the object is scaled jobs, Loop through the PushScalers. (not to loop on the current go routine)scaleToby the scaler's metadata by the all PushScalers metadata so that if there is multiple push scalers were there, the amount of the job doesn't exceed theMaxScale.It is similar to the current implementation of the ScaledJob for non-Push scalers.
If it is ok, I'll implement it and find time to do it.