Skip to content

fix: normalize 2xlarge size spelling - #347

Open
amwarrier wants to merge 1 commit into
mainfrom
aravind/normalize-2xlarge-size
Open

amwarrier wants to merge 1 commit into
mainfrom
aravind/normalize-2xlarge-size

Conversation

@amwarrier

Copy link
Copy Markdown
Contributor

Summary

  • make 2xlarge the canonical v2 size spelling while retaining xxlarge as a compatibility alias
  • normalize legacy values during admission, reconciliation, and v1-to-v2 conversion
  • update generated and embedded CRDs to accept both spellings

Testing

  • go test ./api/v1 ./api/v2 ./internal/controller/reconciler ./internal/webhook/v2
  • go vet ./...
  • make manifests sync-crd-embed

@amwarrier
amwarrier requested a review from a team as a code owner August 27, 2026 21:34

@devin-ai-integration devin-ai-integration Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Devin Review found 1 potential issue.

Devin Review

if size == "" {
size = legacyDefaultSize
}
size = string(appsv2.Size(size).Canonical())

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🟡 Legacy xxlarge per-app resource overrides dropped in conversion

When a converted v1 config uses the legacy xxlarge size, Canonical() rewrites the sizing lookup key to 2xlarge, but the user's own values still key their per-size block under xxlarge, so it is not found. The per-application resource requests and limits are dropped, and the migrated app falls back to default manifest sizing.

Prompt for agents
In legacyResourcesFromSection (api/v1/weightsandbiases_conversion_overrides.go), the resolved size is canonicalized (xxlarge -> 2xlarge) before being used to index the user's own v1 values sizing block at path {"sizing", size, "resources"}. That sizing block is user-supplied v1 helm values, which for a legacy config are keyed by the legacy spelling (xxlarge). Canonicalizing the lookup key to 2xlarge means a user block keyed sizing.xxlarge.resources is no longer matched, silently dropping the per-application resource override (regression vs. the pre-PR behavior which used the raw size string and mirrored the legacy chart). Consider looking up the sizing block using both the raw size and its canonical form (e.g. merge sizing[size] and, if different, sizing[canonical]), or simply keep the raw size for this user-values lookup, so both xxlarge- and 2xlarge-keyed v1 sizing blocks resolve correctly. Note the manifest-side lookups in internal/controller/reconciler/sizing.go legitimately canonicalize because manifests now use 2xlarge keys; this conversion path reads user data and must not assume canonical keys.
Devin Review

Was this helpful? React with 👍 or 👎 to provide feedback.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant