Skip to content

fix(validation): apply HPA scale target bounds per metric - #6140

Merged
github-actions[bot] merged 1 commit into
kserve:masterfrom
UgaTheDev:fix/hpa-scale-target-precedence
Sep 14, 2026
Merged

github-actions[bot] merged 1 commit into
kserve:masterfrom
UgaTheDev:fix/hpa-scale-target-precedence

Conversation

@UgaTheDev

Copy link
Copy Markdown
Contributor

What this PR does / why we need it:

validateScalingHPACompExtension checks if metric == MetricCPU && target < 1 || target > 100. Go binds && tighter than ||, so this parses as (metric == MetricCPU && target < 1) || (target > 100): the upper bound applies to every metric, and a memory target over 100 is rejected with the CPU "target utilization percentage" message. The separate memory branch below it then only ever fires for target < 1, with a "greater than 1 MiB" message even though memory ScaleTarget on the HPA path is a utilization percentage.

This replaces both branches with the existing validateTargetUtilization helper, so CPU and memory targets get the same [1, 100] bound and the same message, matching what the KEDA validation path already does. Accepted values do not change: memory targets in [1, 100] were already the only ones that passed. Only the error text for out-of-range memory targets changes.

Which issue(s) this PR fixes:

Fixes #5981

Feature/Issue validation/testing:

  • Added table-driven cases to TestAutoscalerClassHPA for CPU and memory at 0, 1, 100 and 101. The memory 101 case fails on master with the CPU-worded error and passes here with the unified message.
  • go test ./pkg/apis/serving/v1beta1/ -run TestAutoscalerClassHPA -count=1 passes; gofmt -l clean.

Special notes for your reviewer:

The removed "target memory should be greater than 1 MiB" message was unreachable for any value the first branch did not already reject, except target < 1 for memory; that case is now covered by the shared message.

Checklist:

  • Have you added unit/e2e tests that prove your fix is effective or that this feature works?
  • Has code been commented, particularly in hard-to-understand areas?
  • Have you made corresponding changes to the documentation?

Release note:

Fix HPA scaleTarget validation so CPU and memory utilization targets are both bounded to [1, 100] with a consistent error message.

🤖 Generated with Claude Code

https://claude.ai/code/session_01Qnxf2u2kSBxRM1AT7kD8BD

Fixes kserve#5981

The validateScalingHPACompExtension function had an operator precedence bug
where the condition 'metric == MetricCPU && target < 1 || target > 100' was
evaluated as '(metric == MetricCPU && target < 1) || (target > 100)', causing:
1. The upper bound check to apply to all metrics instead of just CPU
2. Memory targets > 100 to be rejected with a CPU-specific error message
3. The memory-specific validation to use wrong semantics (MiB vs percentage)

Fix by reusing the existing validateTargetUtilization helper, which properly
enforces [1-100] bounds for both CPU and memory metrics, matching the pattern
used in validateScalingKedaCompExtension.

Signed-off-by: Claude Fable 5.1 <[email protected]>
Co-Authored-By: Claude Fable 5.1 <[email protected]>
Claude-Session: https://claude.ai/code/session_01Qnxf2u2kSBxRM1AT7kD8BD
Signed-off-by: Kush Zingade <[email protected]>
@github-actions
github-actions Bot requested review from Jooho and spolti September 5, 2026 02:26
@spolti

spolti commented Sep 14, 2026

Copy link
Copy Markdown
Contributor

/lgtm
/approve

Thanks @UgaTheDev

@github-actions github-actions Bot added the lgtm label Sep 14, 2026
@github-actions
github-actions Bot merged commit d00170b into kserve:master Sep 14, 2026
68 of 70 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

validateScalingHPACompExtension: operator precedence bug leaves HPA memory ScaleTarget's [1-100] cap effectively broken

2 participants