AWS: fix int32 overflow computing memory from InstanceRequirements by pujitha24 · Pull Request #10171 · kubernetes/autoscaler

pujitha24 · 2026-08-21T14:22:38Z

What type of PR is this?

/kind bug

What this PR does / why we need it:

For an ASG that uses attribute-based InstanceRequirements (MixedInstancesPolicy, no
explicit instance-type overrides), updateCapacityWithRequirementsOverrides in
cloudprovider/aws/aws_manager.go computed the synthetic template node's memory
capacity as int64(*instanceRequirements.MemoryMiB.Min*1024*1024).

Since the AWS SDK v2 migration, MemoryMiB.Min is *int32 (it was *int64 in SDK
v1). The int64() cast wraps the whole product, so *Min * 1024 * 1024 is evaluated
in int32 before the cast is applied. For any Min of 2048 MiB (2 GiB) or more this
overflows int32 and wraps — e.g. 8192 MiB wraps to 0. The template node then
advertises ~0 memory capacity, every pending pod fails the NodeResourcesFit
predicate with "Insufficient memory", and the node group never scales up from zero.

This PR moves the int64() cast to the Min operand so the multiplication happens
in int64, matching the pre-SDK-v2-migration behavior.

It also updates the existing TestBuildNodeFromTemplate unit test, which exercised
this code path with MemoryMiB.Min = 4 — too small to trigger the overflow, so it
did not catch the regression. The test now uses Min = 8192, which reproduces the
exact wraparound.

Which issue(s) this PR fixes:

Fixes #10167

Special notes for your reviewer:

Validation performed locally (no live cluster available in this environment):

With only the test change applied and the fix reverted, the updated test fails:
go test ./cloudprovider/aws/... -run 'TestBuildNodeFromTemplate$' -v reports
expected: 8589934592, actual: 0, reproducing the exact overflow described in the
issue.
With the fix applied, go test -race ./cloudprovider/aws/... -vet=all (mirroring
this repo's make test-ci invocation) passes.
gofmt -s -l on both changed files reports no issues.
Checked for the same int64(X * const * const) cast-after-multiply pattern
elsewhere in aws_manager.go: VCpuCount.Min and AcceleratorCount.Min are cast
directly with no multiplication (no overflow risk), and the other in-file use of
*1024*1024 operates on MemoryMb, which is already int64. No other instance of
this bug exists in this file.
master CI is currently green (checked via gh run list --branch master).

Does this PR introduce a user-facing change?

Fixed a bug in the AWS cloud provider where scale-from-zero for ASGs using
attribute-based `InstanceRequirements` (MixedInstancesPolicy, no instance type
overrides) with `MemoryMiB.Min` >= 2048 computed a memory capacity of 0 for the
synthetic template node due to an int32 overflow, causing pods to fail scheduling
with "Insufficient memory" and the node group to never scale up.

Additional documentation e.g., KEPs (Kubernetes Enhancement Proposals), usage docs, etc.:

Summary by CodeRabbit

Bug Fixes
- Corrected reported EC2 instance memory capacity so values are accurately converted to bytes.
- Fixed node template memory calculations for instances with memory requirements such as 8192 MiB.

Motivation: For an ASG using attribute-based InstanceRequirements (MixedInstancesPolicy, no instance type overrides), updateCapacityWithRequirementsOverrides computed the synthetic template node's memory capacity as: int64(*instanceRequirements.MemoryMiB.Min*1024*1024) Since the AWS SDK v2 migration, MemoryMiB.Min is *int32 (previously *int64 in SDK v1). The int64() cast wraps the whole product, so the multiplication by 1024*1024 is evaluated in int32 before the cast is applied. For any Min of 2048 MiB (2 GiB) or greater this overflows int32 and wraps, e.g. 8192 MiB wraps to 0. The resulting template node then advertises ~0 memory capacity, every pending pod fails the NodeResourcesFit predicate with "Insufficient memory", and the node group never scales up from zero. Approach: Move the int64() cast to the Min operand so the multiplication happens in int64, matching the existing pattern used for other fields (e.g. AWS SDK v1 behavior before the migration). Also updates the existing TestBuildNodeFromTemplate unit test, which exercised this code path with MemoryMiB.Min = 4 - too small to trigger the overflow, so it did not catch the regression. The test now uses Min = 8192, which reproduces the exact wraparound described above. Validation: - With only the test change applied (fix reverted), the updated test fails: `go test ./cloudprovider/aws/... -run 'TestBuildNodeFromTemplate$' -v` reports "expected: 8589934592, actual: 0", reproducing the overflow. - With the fix applied, `go test -race ./cloudprovider/aws/... -vet=all` (mirroring this repo's `make test-ci` invocation) passes. - `gofmt -s -l` on both changed files reports no issues. - This change is scoped to cloudprovider/aws; no other field in this file multiplies a *int32 SDK value by a constant before casting to int64. Report: kubernetes#10167 Signed-off-by: Pujitha Paladugu <10557236+pujitha24@users.noreply.github.com> Assisted-by: claude-sonnet-5 (via Claude Code)

kubernetes-prow · 2026-08-21T14:22:46Z

This issue is currently awaiting triage.

If SIG Autoscaling contributors determines this is a relevant issue, they will accept it by applying the triage/accepted label and provide further guidance.

The triage/accepted label can be added by org members by writing /triage accepted in a comment.

Details

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

kubernetes-prow · 2026-08-21T14:22:48Z

Hi @pujitha24. Thanks for your PR.

I'm waiting for a kubernetes member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work.

Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

Details

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.

kubernetes-prow · 2026-08-21T14:22:51Z

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: pujitha24
Once this PR has been reviewed and has the lgtm label, please assign gjtempleton for approval. For more information see the Code Review Process.

The full list of commands accepted by this bot can be found here.

Details

Needs approval from an approver in each of these files:

cluster-autoscaler/cloudprovider/aws/OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

coderabbitai · 2026-08-21T14:23:02Z

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro Plus

Run ID: 2dbbedfd-1fb8-4cd6-9660-6d9406a62655

📥 Commits

Reviewing files that changed from the base of the PR and between ce048aa and 0fabde7.

📒 Files selected for processing (2)

cluster-autoscaler/cloudprovider/aws/aws_manager.go
cluster-autoscaler/cloudprovider/aws/aws_manager_test.go

Included review availability: Your plan provides up to 8 included reviews per hour; 7 remain after this review.

📝 Walkthrough

Walkthrough

The AWS provider now converts the minimum MemoryMiB value to int64 before multiplying by the byte conversion factor. The test now validates an 8192 MiB requirement and its byte capacity.

Changes

AWS memory capacity calculation

Layer / File(s)	Summary
Memory conversion and validation `cluster-autoscaler/cloudprovider/aws/aws_manager.go`, `cluster-autoscaler/cloudprovider/aws/aws_manager_test.go`	The provider performs memory conversion with int64 arithmetic. The test expects 8192 MiB to produce the corresponding byte capacity.

Estimated code review effort: 1 (Trivial) | ~5 minutes

Merge Risk: ⚪ Minimal · up to 0fabd

This localized fix prevents incorrect memory capacity calculations for AWS instance requirements and adds a regression test for the overflow case; no actionable merge-blocking risk remains after normal checks and review.

🚥 Pre-merge checks | ✅ 4 | ❌ 1

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%. Docstring coverage is scoped to functions touched by this diff. Analyzed 1 functions across 2 files.	Write docstrings for the functions missing them to satisfy the coverage threshold.

✅ Passed checks (4 passed)

Check name	Status	Explanation
Linked Issues check	✅ Passed	The code casts MemoryMiB.Min to int64 before conversion, and the test covers 8192 MiB overflow, satisfying issue `#10167`.
Out of Scope Changes check	✅ Passed	The changes are limited to the AWS memory conversion fix and its focused regression test.
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title clearly and concisely describes the primary fix for the int32 overflow in AWS memory computation from InstanceRequirements.

✨ Finishing Touches

🧪 Generate unit tests (beta)

Create PR with unit tests

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

_{Comment @coderabbitai help to get the list of available commands.}

neoLsH · 2026-08-25T15:23:28Z

Verified this locally against master — two findings that may help review:

This appears to be the only overflow site in the AWS provider: template.InstanceType.MemoryMb at aws_manager.go:286 is int64 (ec2_instance_types.go:25), and VCpuCount.Min / AcceleratorCount.Min are cast to int64 before being passed to NewQuantity with no multiplication involved. So the one-line fix covers it.
The updated test is an effective regression test. On the cluster-autoscaler module:
- with this PR: go test ./cloudprovider/aws/ -run TestBuildNodeFromTemplate passes;
- reverting aws_manager.go to master while keeping the new test: it fails with expected: 8589934592 (8 GiB wraps to 0 in int32, exactly the scale-from-zero symptom from AWS: int32 overflow when computing memory from InstanceRequirements breaks scale-from-zero (NodeResourcesFit "Insufficient memory") #10167).

kubernetes-prow Bot removed the do-not-merge/needs-area Indicates that a PR should not merge because it lacks an area label. label Aug 21, 2026

kubernetes-prow Bot requested review from BigDarkClown and gjtempleton August 21, 2026 14:22

kubernetes-prow Bot added the size/XS Denotes a PR that changes 0-9 lines, ignoring generated files. label Aug 21, 2026

Navigation Menu

Uh oh!

AWS: fix int32 overflow computing memory from InstanceRequirements - #10171

AWS: fix int32 overflow computing memory from InstanceRequirements#10171
pujitha24 wants to merge 1 commit into
kubernetes:masterfrom
pujitha24:auto/issue-10167

pujitha24 commented Aug 21, 2026 •

edited by coderabbitai Bot

Loading

Uh oh!

kubernetes-prow Bot commented Aug 21, 2026

Uh oh!

kubernetes-prow Bot commented Aug 21, 2026

Uh oh!

kubernetes-prow Bot commented Aug 21, 2026

Uh oh!

coderabbitai Bot commented Aug 21, 2026 •

edited

Loading

Walkthrough

Changes

❌ Failed checks (1 warning)

Uh oh!

neoLsH commented Aug 25, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Uh oh!

Conversation

pujitha24 commented Aug 21, 2026 • edited by coderabbitai Bot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

What type of PR is this?

What this PR does / why we need it:

Which issue(s) this PR fixes:

Special notes for your reviewer:

Does this PR introduce a user-facing change?

Additional documentation e.g., KEPs (Kubernetes Enhancement Proposals), usage docs, etc.:

Summary by CodeRabbit

Uh oh!

kubernetes-prow Bot commented Aug 21, 2026

Uh oh!

kubernetes-prow Bot commented Aug 21, 2026

Uh oh!

kubernetes-prow Bot commented Aug 21, 2026

Uh oh!

coderabbitai Bot commented Aug 21, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Walkthrough

Changes

❌ Failed checks (1 warning)

Uh oh!

neoLsH commented Aug 25, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

pujitha24 commented Aug 21, 2026 •

edited by coderabbitai Bot

Loading

coderabbitai Bot commented Aug 21, 2026 •

edited

Loading