Introduce activationThreshold/minMetricValue for all scalers

[zroubalik]

Proposal

Current activation (ie. scaling 0<->1) is happening if there's any activity on the target scaler, ie. the condition for comparison is metricFromScaler > 0. The threshold property on individual scalers is not respected, it is just applied to 1<->N scaling.
There are 2 scalers that supports flexible activation configuration, AWS Cloudwatch and Huawei Cloudeye (via minMetricValue property), where the default value is 0. The condition for comparison in this case is: metricFromScaler > minMetricValue.

We might want to introduce the same capability for all scalers.

• introduce activation threshold for all scalers
• properly document activation (the current state and the new option)

Pending to implement:

• Influx Scaler -> Feat:Introduce activationValue/minMetricValue for InfluxDB scaler #3516
• Kafka Scaler -> feat: Introduce activationThreshold/minMetricValue for Kafka Scaler #3501
• New Relic Scaler -> feat: introduce activationThreshold for New Relic Scaler #3427
• RabbitMQ Scaler -> Activation threshold (activationValue) for Rabbitmq #2831
• Redis Scaler -> feat: Introduce activationThreshold/minMetricValue for Redis Scalers #3415

Will not implement this:

• CPU/Memory
• Cron
• Redis Stream -> [HELP NEEDED] feat: Introduce activationThreshold/minMetricValue for Redis Scalers #3415 (comment)

Use-Case

No response

Anything else?

No response

[JorTurFer]

@adborroto , @xoanmm
Maybe anyone of you is interested on this 😉

[adborroto]

About the name of this new property. Will be a generic name or specific by sealer?
IMO, a specific name makes more sense and would be self-explanatory sometimes.

[zroubalik]

Agree, I'd do something that I have suggested on the PR: activation* prefix to the current field that holds the value/queuelength/threshold in each scaler.

But I am definitely open to another options.

[JorTurFer]

What do you think if we use this change to unify those parameters? I mean, we can rename all of them into threshold/activationThreshold and keep the consistency accros all the scalers.
Of course, the current case must be maintained but we can deprecate it. IMO having more options makes the things more complex, and at the end of the day, the "unit" of the threshold depends on the scaler, but the goal is always the same

[ybialik]

We would also like this feature for kafka scaler.

[JorTurFer]

Related with this issue, during the last standup we decided to continue with it for all scalers, and we also agree with using activation* as a prefix for every scaler where * is the current metric name because it has enough context for each scaler users

[zroubalik]

@ybialik as @JorTurFer mentioned, we plan to have this for all scalers, so you can contribute this for Kafka :)

[ybialik]

@zroubalik I am only a user, I can only contribute my feedback :)

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 7 days if no further activity occurs. Thank you for your contributions.

[stale]

This issue has been automatically closed due to inactivity.

[v-shenoy]

Is every scaler done now?

[zroubalik]

Redis Streams is missing because we are not sure about the functionality. If you happen to have Redis Streams knowledge, or know anybody, open a PR for that please!

[zroubalik]

@v-shenoy here is the Redis Streams related discussion: #3415 (comment)

[JorTurFer]

I think this is ready. I close it for the moment