Summary
WVA plans to create and manage HPA and KEDA (ScaledObject) resources for the workloads it autoscales. However, there are integration scenarios — most notably KServe — where the external platform already creates and owns HPA or KEDA objects for the same workload. In these cases, WVA must not create its own HPA/KEDA objects, as two controllers competing over the same autoscaling objects for the same target Deployment leads to undefined and conflicting scaling behavior.
We need an option in WVA to completely disable HPA and/or KEDA object creation so that external controllers can own the autoscaling sub-resources lifecycle exclusively.
In the long term, KServe aims to offload the creation and management of autoscaling sub-resources (HPA, KEDA ScaledObject) entirely to WVA, making WVA the single authoritative owner of the autoscaling lifecycle for inference workloads. However, adopting that model immediately would be a breaking change for KServe — it would require removing or disabling the HPA/KEDA management that KServe currently performs as part of its LLMInferenceService reconciliation. As an incremental step, this issue requests only the ability to disable WVA's HPA/KEDA object creation, so that KServe can continue owning those objects today while the two projects coordinate on the longer-term ownership handoff. Once KServe is ready to stop managing autoscaling sub-resources on its side, WVA can simply enable that path — with no further API changes required.
Summary
WVA plans to create and manage HPA and KEDA (
ScaledObject) resources for the workloads it autoscales. However, there are integration scenarios — most notably KServe — where the external platform already creates and owns HPA or KEDA objects for the same workload. In these cases, WVA must not create its own HPA/KEDA objects, as two controllers competing over the same autoscaling objects for the same targetDeploymentleads to undefined and conflicting scaling behavior.We need an option in WVA to completely disable HPA and/or KEDA object creation so that external controllers can own the autoscaling sub-resources lifecycle exclusively.
In the long term, KServe aims to offload the creation and management of autoscaling sub-resources (HPA, KEDA ScaledObject) entirely to WVA, making WVA the single authoritative owner of the autoscaling lifecycle for inference workloads. However, adopting that model immediately would be a breaking change for KServe — it would require removing or disabling the HPA/KEDA management that KServe currently performs as part of its LLMInferenceService reconciliation. As an incremental step, this issue requests only the ability to disable WVA's HPA/KEDA object creation, so that KServe can continue owning those objects today while the two projects coordinate on the longer-term ownership handoff. Once KServe is ready to stop managing autoscaling sub-resources on its side, WVA can simply enable that path — with no further API changes required.