Support ScaledObject taking over existing HPAs with the same name while they are not managed by other ScaledObject

[pragmaticivan]

Proposal

Support a new field such as advanced.takeOverCurrentHpa that should be able to skip validation webhook when the existing HPA that is being taken over does not have any metadata that indicates it's managed by another ScaledObject

1. hpa name=foo exists.
2. created a new ScaledObject and had set the same attribute name. name=foo but also had set advanced.takeOverCurrentHpa = true.
3. Scaled Object should take over and replace the HPA with a managed one. Validation Webhook should not block it because the existing hpa is not managed by another ScaledObject.

Use-Case

Supports drop-in migrations for companies using HPA that want to easily move existing resources with ScaledObjects.

Is this a feature you are interested in implementing yourself?

Maybe

Anything else?

No response

[pragmaticivan]

This feature might enable the opportunity to create a "Migrator CLI" or similar that should replace the existing HPA yaml with a modified ScaledObject that should take over the previous resource.

[tomkerkhove]

Is your main problem that the webhook is blocking it? Because you can also install it without webhook validation.

Additionally, I believe we should allow you to turn off rules which are tracked in #4067

[pragmaticivan]

@tomkerkhove, the behaviors in the webhook are expected unless someone is trying to migrate their resources in their namespace. This is useful for multi-tenant clusters holding workloads for multiple teams so not all the teams need to perform the migration simultaneously.

[tomkerkhove]

So would it help if you could:

1. Annotate an HPA as "don't complain about this one", and
2. Be able to create a scaled object, but not have it "active"

That way you can create the SO next to your HPA and you can delete the HPA once the SO is created. Would that help?

A migratory CLI could be another route but more work for something "trivial" which would only cover CPU/memory then?

[tomkerkhove]

As discussed in standup, the current thinking is to:

• Use the existing HPA name field to define the name
• Use a new annotation to mark a ScaledObject keda.sh/transfer-hpa-ownership: true

Once that is the case, KEDA will:

• Ignore webhook validation for duplicate HPA for same workload
  • However, still block in case of multiple SOs and when HPA does not have ownership yet
• Configure the HPA to be owned by KEDA
• Provide a warning that take-over was performed
• Add event to ScaledObject CRD that ownership was transferred (history on resource)

[ghost]

Hi, any progress on this issue? Looks like PR still in draft mode
Actually we need this feature so that our users will have Zero downtime during migration!