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

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

Closed
pragmaticivan opened this issue Apr 14, 2023 · 6 comments · Fixed by #4537
Labels
feature All issues for new features that have been committed to feature-request All issues for new features that have not been committed to needs-discussion

Comments

@pragmaticivan
Copy link
Contributor

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 pragmaticivan added feature-request All issues for new features that have not been committed to needs-discussion labels Apr 14, 2023
@pragmaticivan pragmaticivan changed the title Support ScaledObjects taking over existing HPAs with the same name while they are not managed by other ScaledObjects Support ScaledObject taking over existing HPAs with the same name while they are not managed by other ScaledObject Apr 14, 2023
@pragmaticivan
Copy link
Contributor Author

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
Copy link
Member

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
Copy link
Contributor Author

@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
Copy link
Member

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
Copy link
Member

tomkerkhove commented May 9, 2023

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
Copy link

ghost commented Jun 8, 2023

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!

@tomkerkhove tomkerkhove added needs-discussion feature-request All issues for new features that have not been committed to feature All issues for new features that have been committed to and removed feature-request All issues for new features that have not been committed to needs-discussion labels Jun 8, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature All issues for new features that have been committed to feature-request All issues for new features that have not been committed to needs-discussion
Projects
Archived in project
2 participants