Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add support for initialCooldownPeriod On httpScaledObjects #1212

Merged
merged 6 commits into from
Feb 21, 2025

Conversation

shayrybak
Copy link
Contributor

@shayrybak shayrybak commented Dec 11, 2024

Add support for initialCooldownPeriod On httpScaledObjects

Checklist

Fixes #1213

Copy link
Member

@wozniakjan wozniakjan left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

lgtm, thank you! Can you please also re-generate the CRDs?

make manifests

@shayrybak
Copy link
Contributor Author

@wozniakjan added, I always forget that part.

@wozniakjan
Copy link
Member

perfect, thank you. One more thing, can you please sign the last commit?

@zroubalik
Copy link
Member

Should we really do this? We could easily end up in 1-1 relation with ScaledObject's field, I wonder whether we should users encourage to specify this on the SO directly 🤔

@wozniakjan
Copy link
Member

Should we really do this?

given this can affect scaling right after SO creation, before metrics had a chance to get to KEDA and can lead to an immediate scale to 0 on an active deployment that was just onboarded to autoscaling, I think there is a stronger case for having initialCooldownPeriod in HSO than cooldownPeriod which is already there. The cooldownPeriod could be easily changed after HSO creation directly in SO without any negative effects.

@shayrybak
Copy link
Contributor Author

updated.`
@zroubalik this is what we've done temporarily to work around this, but it seems like a lot of effort for such a small change. I understand the use case to have my own SO if I mix other scaler tiriggers, but for a simple use case it's nice to have this.

Like I said in the issue, the use case is starting up sandbox environments so it's nice to have them up before they automatically scale down based on usage.

@zroubalik
Copy link
Member

Makes sense, no objections from my side.

@zero101010
Copy link

Should we really do this? We could easily end up in 1-1 relation with ScaledObject's field, I wonder whether we should users encourage to specify this on the SO directly 🤔

Yes. it's really useful. Yesterday I need to do a workaround to use this. I'm really excited to have this on keda.

@zroubalik
Copy link
Member

Yesterday I need to do a workaround to use this

Just out of curiosity, what workaround that was?

Signed-off-by: Jan Wozniak <[email protected]>
@wozniakjan wozniakjan enabled auto-merge (squash) February 21, 2025 12:35
@wozniakjan wozniakjan merged commit d15f442 into kedacore:main Feb 21, 2025
18 checks passed
@zero101010
Copy link

zero101010 commented Feb 21, 2025

Yesterday I need to do a workaround to use this

Just out of curiosity, what workaround that was?

I created the httpScaleObject and patch the scaleObject to add initalCooldownPeriod and then apply the other resources. I'm really happy that this feature it's added

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Add support for InitialCooldownPeriod
5 participants