Adding configuration for time required to scale deployments in

[someshkoli]

Currently I believe there's not such configuration where we can tell how much time to wait for deployments to scale down to zero.
Can someone point me to where exactly we have setup timeout loops ?
Will raise a pr for this feature ^

Use-Case

Have different types of workloads which require different scale down timeouts.

Tell us more what you'd like to achieve

Specification

Tell us in detail how this feature should work

[tomkerkhove]

KEDA Core has this as part of the ScaledObject for scaling to 0 as per cooldownPeriod so it should be feasible to do this.

For the rest, it's up to the HPA to define when to scale in if I'm not mistaken - Correct @JorTurFer / @zroubalik?

[tomkerkhove]

The request from @Kaitou786 in #550 is for scaling to 0 so cooldownPeriod should work.

[someshkoli]

Will raise a pr for this 🙌

[someshkoli]

@tomkerkhove PTAL ^ ? this should do the job I suppose.

[JorTurFer]

yeah, cooldownPeriod is for the scaling from/to 0, the rest of the scaling is modified by the advanced section of the HPA, in KEDA core we have support to it in the ScaledObject, maybe it's something we can expose here too

[tomkerkhove]

@JorTurFer Let's do on a feature-per-feature basis to avoid making it too complex and ensure it works properly with this add-on (ie scaling mechanics/scenarios, etc)

[holygrolli]

after trying this feature out with v0.4.0 I created a HTTPScaledObject

apiVersion: http.keda.sh/v1alpha1
kind: HTTPScaledObject
spec:
  host: host.mydomain.com
  replicas:
    max: 1
    min: 0
  scaleTargetRef:
    deployment: mydeployment
    port: 80
    service: mysvc
  scaledownPeriod: 600
  targetPendingRequests: 100

apparently the cooldownPeriod is never being put into the ScaledObject

apiVersion: keda.sh/v1alpha1
kind: ScaledObject
spec:
  advanced:
    restoreToOriginalReplicaCount: true
  maxReplicaCount: 1
  minReplicaCount: 0
  pollingInterval: 1
  scaleTargetRef:
    kind: Deployment
    name: mydeployment
  triggers:
  - metadata:
      host: host.mydomain.com
      scalerAddress: keda-add-ons-http-external-scaler.keda:9090
    type: external-push

did I miss something?

[tomkerkhove]

Fixed in #587

[BottlecapDave]

I've just been hit by this too. When will the fix be released? I'm on chart version 0.4.1 and it doesn't seem to be passed through.

[holygrolli]

the chart v0.4.1 still contains app version v0.4.0 so we will need an update on both http-add-on and the chart

[JorTurFer]

You can use a specific docker tag, we have reintroduced the docker tag generated from commit sha, so you can use ityo have those changes. We don't plan to release another version soon, we released 0.4.0 10 days ago.
Tag 8b1df1f doesn't have any breaking change yet, so you can use it for having the fix

[BottlecapDave]

I'm probably wrong, but I believe this was an error with the chart not the underlying app, so a docker tag won't help in this situation?

[JorTurFer]

Hi @BottlecapDave ,
I don't think so, ScaledObjects are generated by the app as part of HTTPScaledObject processing. I mean, if the error isn't that the value is missing in the HTTPScaledObject (and I have understood that this case is related with the ScaledObject), the app is the responsible for generating them.
What is the problem you are facing exactly? Maybe it's similar but not the same

[holygrolli]

just for protocol I figured out the first usable image tag after merging #587
I only need to pass these values to the keda-http-add-on Helm chart:

images:
  tag: 8b1df1f

you probably can use canary tag too but this was the first tag after fixing the ScaledObjects bug.
Thank you all

[JorTurFer]

yeah, @holygrolli is right.
I don't recommend to use canary directly because any breaking change could introduce a problem in your clusters, using a fixed tag is better for stability