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

ScaledObject created with transfer-hpa-ownership annotation does not set .status.hpaName #6336

Open
SriRamanujam opened this issue Nov 15, 2024 · 4 comments
Labels
bug Something isn't working

Comments

@SriRamanujam
Copy link

SriRamanujam commented Nov 15, 2024

Report

When creating a ScaledObject with the scaledobject.keda.sh/transfer-hpa-ownership annotation, it does not set .status.hpaName.

Expected Behavior

Adopted/transferred-ownership ScaledObject resources should have .status.hpaName set to the name of the HPA referenced in .spec.advanced.horizontalPodAutoscalerConfig.name

Actual Behavior

.status.hpaName is unset in all cases except when KEDA was responsible for the initial creation of the managed HPA.

Steps to Reproduce the Problem

  1. Create an HPA.
  2. Create a ScaledObject with the transfer-hpa-ownership annotation combined with .spec.advanced to have KEDA take over the HPA.
  3. Observe that .status.hpaName never gets set on the ScaledObject.

Logs from KEDA operator

No response

KEDA Version

2.14.0

Kubernetes Version

1.29

Platform

Any

Scaler Details

No response

Anything else?

I think that this may be an issue for any ScaledObject where the first reconcile loop doesn't go through this block, tracing through the code this seems to be the only place where status.HpaName is set and it's only called when HPAs are initially created.

@SriRamanujam SriRamanujam added the bug Something isn't working label Nov 15, 2024
@SpiritZhou
Copy link
Contributor

Are you willing to fix this bug? :)

@SriRamanujam
Copy link
Author

@SpiritZhou I'm happy to take a crack at it, but I wanted to confirm that this is in fact a bug and not intended behavior or otherwise load-bearing :D

@SpiritZhou
Copy link
Contributor

I believe this is a bug. but we can ask @zroubalik @JorTurFer @wozniakjan to double check

@JorTurFer
Copy link
Member

It looks as a bug, yeah

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
Status: To Triage
Development

No branches or pull requests

3 participants